AI in Healthcare
RAG for Clinical Documents: Risks & Evaluation
RAG for clinical documents: ingest FHIR notes, retrieve and cite evidence, protect PHI, and test faithfulness, recall and abstention before release.
October 21, 2026Read more
NextGen Healthcare's licensing change left organizations able to keep an earlier open-source release while moving future Mirth Connect releases to a proprietary commercial model, according to its official licensing announcement. For engineers evaluating Mirth Connect alternatives, the immediate problem is preserving production message behavior while deciding who will own maintenance, support, and recovery. The decision requires comparing community-maintained runtimes, supported interface engines, and cloud healthcare services against the same operational evidence.
The shortlist should follow the workload. Existing HL7 interfaces require proven transport, transformation, acknowledgement, and recovery behavior; FHIR-oriented applications may benefit from a separate data-service layer. Neither approach removes the need to verify what happens when a destination fails or a message needs replay.
Why the Mirth licensing change matters
NextGen ended open-source distribution with version 4.6 in 2025. Version 4.5.2 is the last open-source release. Staying on it is a different maintenance proposition from adopting the commercial product line described in the announcement above, because NextGen's security fixes and new features now ship in licensed releases.
Continuing an existing deployment and upgrading to a maintained release are separate decisions. An organization can preserve its current environment while assessing replacements, but it needs an explicit owner for vulnerability assessment, dependency maintenance, and any compensating controls. Buying a commercial license also requires scrutiny: procurement must establish which releases, support services, and escalation commitments the agreement includes.
Establish the ownership boundary
We would start with a written decision record covering:
Upgrade authority, including who approves runtime changes and how the organization validates them.
Maintenance responsibility, identifying who investigates vulnerabilities and delivers deployable fixes.
Support coverage, distinguishing product troubleshooting from interface operations and incident recovery.
Source-code governance, covering modifications, redistribution, and the obligations attached to the deployed release.
For legal review, Mozilla's MPL 2.0 FAQ explains the license used by earlier open-source Mirth Connect releases and their community forks. Counsel should still assess the actual license and distribution arrangement rather than infer rights from the phrase open source.
The same ownership questions should frame any assessment of healthcare integration services. The relevant deliverable is a supportable operating model with documented responsibilities, rather than a replacement runtime alone.
A licensing change doesn't establish that migration is necessary. It establishes that retaining the current architecture now requires a deliberate maintenance decision. The risk of replacing working interfaces belongs in that decision alongside licensing, source access, and future upgrade control.
What an interface engine does
A vendor demo that delivers one clean HL7 message proves very little. The behavior that predicts production risk is what the engine does when the message is malformed, the destination is down, or the acknowledgement never arrives. Follow one representative inbound message through its full lifecycle and ask for evidence at each handoff.
In a complete trace, the engine receives the message and identifies its source, transport, and processing contract. It parses and validates content against the interface's agreed rules, then applies mappings, terminology decisions, filters, and routing conditions. It produces the required acknowledgement at the agreed processing boundary, delivers downstream, and absorbs an unavailable destination without losing accountability. The runtime should expose enough logging to reconcile receipt, processing, and final delivery for any given message. Acceptance testing should run against the organization's own interfaces, including the malformed ones.
A second check concerns where responsibilities sit. A proposal may concentrate these functions in one runtime or distribute them across services, and either arrangement can work if ownership is explicit:
| Capability | Acceptance evidence to request |
|---|---|
| Message processing | Reprocessing, queuing, and error handling for a failed delivery |
| FHIR persistence and API access | How HL7-sourced data becomes queryable FHIR resources |
| API authorization | The component enforcing access control on exposed endpoints |
| Business workflow orchestration | Where exception review and human decisions occur |
That boundary matters for estates carrying HL7 v2, CDA, DICOM, X12, partner-specific formats, FHIR APIs, or subscriptions. Treat each required interaction as a separate acceptance item, since one standards label rarely covers the others. Ekipa's discussion of healthcare data interoperability gives additional context for drawing that line.
Draw the same line between interface delivery and workflow automation. A delivered message can still require application-level reconciliation, exception review, or a human decision, so document where the engine's responsibility ends and the receiving workflow begins. During a phased migration, that documented evidence trail is also what lets the legacy engine and its replacement run side by side while interfaces move over one at a time.
The main Mirth Connect alternative groups
The alternatives fall into categories with different ownership models. Evaluate the category before comparing individual implementations, because an unsuitable operating model won't become suitable through additional connectors.
Community-maintained runtimes
A community fork merits consideration when the organization wants source access and can assess the maintenance process itself. Shared ancestry should be treated as a reason to investigate compatibility, not evidence that channel behavior, extensions, or database changes are interchangeable.
The two best-known options are the community-governed Open Integration Engine (OIE), which continues the Mirth Connect codebase under the Mozilla Public License 2.0, and BridgeLink, an open-source fork of Mirth Connect 4.5.2 maintained by Innovar Healthcare with optional paid support. Some integration vendors also distribute supported builds of OIE. Because both projects began in 2025, check each one's release cadence, governance and record of handling security advisories before committing production interfaces.
Request release artifacts, security-reporting procedures, dependency information, and the process for moving a fix into a deployable build. Establish who can support the exact distribution you intend to run.
Supported commercial engines
Commercial interface engines belong on the shortlist when contractual product support is important. Evaluate their configuration model, deployment requirements, transformation tooling, and operational access through a representative implementation.
Widely used commercial options include NextGen's licensed Mirth Connect (version 4.6 and later), Rhapsody, InterSystems HealthShare Health Connect, Infor Cloverleaf and iNTERFACEWARE Iguana. Staying with licensed Mirth Connect usually means the least channel rework; moving to another engine means rebuilding and retesting channels, so the migration effort belongs in the price comparison.
A support agreement should specify whether the supplier handles software defects, channel defects, infrastructure incidents, or some combination. Those responsibilities can sit with different parties even when procurement buys them together.
Cloud healthcare building blocks
Cloud healthcare services should be evaluated as architectural components. Ask which responsibilities the service accepts and which remain in the integration runtime, application code, or customer operations team.
Cloud examples include Azure Health Data Services, Google Cloud Healthcare API and AWS HealthLake. These are mainly managed FHIR data services, with some support for HL7 v2 or DICOM depending on the provider, so most organizations still pair them with an integration layer that handles MLLP feeds, transformations and acknowledgements. For moving HL7 v2 interfaces toward FHIR, see our HL7 v2 to FHIR migration roadmap, and for EHR-side work, see Epic EHR integration.
The unresolved questions are concrete:
Legacy continuity, including how existing transport and acknowledgement behavior will be preserved.
Recovery ownership, identifying who restores processing and reconciles queued messages.
Transformation maintenance, covering versioned mappings and partner-specific exceptions.
Operational visibility, defining how operators trace a message across service boundaries.
A cloud proposal may be appropriate for a new API-oriented workload while leaving existing message processing in place. That coexistence can be a valid target architecture rather than an incomplete migration.
Mirth Connect alternatives at a glance
| Option | Type | Licensing and support | Main consideration |
|---|---|---|---|
| Stay on Mirth Connect 4.5.2 | Last open-source release | No new open-source releases from NextGen | A short-term bridge; you own security and maintenance |
| NextGen Mirth Connect 4.6 and later | Commercial engine | Licensed, with vendor support | Most direct path for existing channels |
| Open Integration Engine | Community fork | MPL 2.0; community and third-party support | Same lineage as Mirth; verify compatibility and security response |
| BridgeLink | Open-source fork | Optional paid support from Innovar Healthcare | Same lineage as Mirth; review release history |
| Rhapsody, InterSystems Health Connect, Infor Cloverleaf, Iguana | Commercial engines | Licensed, with vendor support | Channels must be rebuilt and retested |
| Azure, Google Cloud and AWS health data services | Managed cloud services | Cloud subscription | Usually paired with an integration layer for HL7 v2 |
Product names and capabilities change, so confirm current versions, support terms and security advisories directly with each project or vendor.
Compare the options by decision criteria
A shortlist decision should rest on evidence a team can produce during evaluation. Each criterion below is framed as a question with an observable answer.
Mirth Connect alternatives by selection criterion
| Option or group | Licensing model | Hosting model | FHIR support | Learning curve | Decision question |
|---|---|---|---|---|---|
| Existing open-source release | Historical open-source release | Existing customer-operated environment | Validate deployed capabilities | Existing knowledge, plus maintenance obligations | Can the organization sustain this release responsibly? |
| Commercial continuation | Proprietary commercial license | Confirm contracted deployment options | Verify release and licensed components | Upgrade validation and revised support procedures | Does continuity justify the commercial operating model? |
| Community-maintained fork | Inspect the selected distribution's license | Verify supported deployment topology | Test required interactions and extensions | Compatibility testing and maintainer procedures | Who supplies and supports deployable fixes? |
| Supported commercial interface engine | Commercial agreement | Confirm customer-operated or managed options | Require workload-specific demonstration | Mapping, tooling, deployment, and operator retraining | Does support cover the failure modes that matter? |
| Cloud healthcare data service | Cloud service agreement | Provider-operated service with customer configuration | Verify API, persistence, and authorization requirements | Service integration and distributed troubleshooting | Which engine responsibilities still need implementation? |
| Custom integration stack | Component-specific licenses | Customer-defined | Depends on selected components and implementation | Software development and ongoing operations | Can the organization maintain the complete system? |
The table avoids unsupported ratings such as easy, enterprise-grade, or fully FHIR-compatible. Learning curve should be measured through actual work: implementing a transformation, promoting a configuration, diagnosing a failed delivery, and recovering a stalled interface.
FHIR claims deserve the same scrutiny. A proposal claiming FHIR R4 support may ship only a read-only client; ask for a create transaction against a sandbox Patient resource and a CapabilityStatement listing the supported interactions. Where a proposal mixes API access with traditional message channels, Ekipa's FHIR versus HL7 comparison can help evaluators classify which integration pattern each interface performs before scoring it.
Make the comparison testable
Run the same acceptance package against every shortlisted category. Configuration evidence should show where endpoints, credentials, mappings, and environment settings live. Operational demonstrations should cover failed destinations, replay, deployment rollback, and audit retrieval. Support evidence should identify escalation routes and the boundary between supplier and customer work.
Record unknowns as unknowns.
A missing demonstration becomes an evaluation task rather than a favorable assumption. That discipline stops a familiar configuration model from receiving an automatic advantage, and it stops a newer architecture from collecting credit for capabilities that still require custom engineering.
Evaluate scalability, security, and interoperability
Define scalability through workload and recovery requirements. Benchmark representative ingestion, transformations, FHIR create/read/update/delete operations, searches, exports, retries, and audit activity in the proposed environment. Measure queue growth and recovery after downstream interruption alongside successful processing.
A useful test includes malformed messages, destination timeouts, duplicate delivery attempts, and operational access during backlog recovery. Separate the runtime's behavior from the behavior of external databases, authorization services, and receiving systems. Require the proposal to explain which component limits throughput under each test.
Require evidence for security controls
Under 45 CFR § 164.312, HIPAA technical safeguards include access control, unique user identification, emergency access procedures, audit controls, integrity, authentication, and transmission security. Encryption is an addressable implementation specification, not a universally mandatory setting, as explained in the HHS Security Rule overview.
The covered entity or business associate owns the risk assessment and documented safeguard decisions. Engineering should supply:
Access evidence, including account provisioning, least-privilege configuration, and rejected unauthorized requests.
Audit evidence, showing who changed configurations and how records are protected.
Integrity evidence, demonstrating detection or prevention of unauthorized changes.
Transport evidence, identifying authentication, encryption decisions, and certificate monitoring for each connection.
HHS also explains that open-network transmission requires adequate protection and documented, risk-based decisions in its guidance on transmitting electronic protected health information. A secured administration console therefore can't serve as evidence for every message transport.
Test authorization across the whole path
For SMART on FHIR, require capability documentation and authorization tests that exercise the complete request path. The HL7 US Core guidance on SMART scopes describes backend-service capabilities, token introspection, and resource-level and granular access scopes.
Test denied access as deliberately as permitted access. Evidence should show that the gateway, authorization component, adapter, and data service preserve the intended restrictions, including patient-specific restrictions where applicable.
Choose by deployment model and use case
Deployment model decides who owns continuity when an interface fails, and after the Mirth licensing change that question outweighs any feature comparison.
A community-maintained runtime can be a defensible choice for a stable, lower-criticality estate when internal engineers own maintenance and recovery. The test is demonstrated capacity: who covers incidents when the primary maintainer is unavailable.
Clinical and revenue-critical interfaces raise the stakes. Compare supported commercial and managed operating models against internal ownership, pricing in validation effort, operational staffing, disaster recovery, and downtime exposure. A license-only comparison leaves the most consequential responsibilities unpriced.
Each model carries a distinct continuity risk.
| Deployment model | Best-fit use case | Continuity risk to test |
|---|---|---|
| Self-hosted community runtime | Stable, lower-criticality estates | Maintainer coverage, rebuild speed |
| Commercial supported engine | Clinical and revenue-critical flows | Where support ends and internal on-call begins |
| Managed service | Teams without dedicated integration operations staff | Escalation path, data residency |
| Coexistence during migration | Phased moves off the current engine | Split troubleshooting, duplicate delivery |
A worked scenario: mixed legacy and FHIR workloads
Consider a hypothetical provider running inbound MLLP feeds, outbound FHIR API interactions, and a legacy CDA workflow, weighing a cloud data service against a supported interface engine. Walking the data flow settles the question: the team documents when each sending system expects acknowledgement, the engine proves parsing, mapping, routing, and recoverable delivery, and the cloud service demonstrates the required FHIR persistence and API behavior. The CDA workflow stays on its existing path until a replacement passes separate validation, and operations tests tracing and reconciliation across both implementations before approving coexistence.
Sign-off divides cleanly in that scenario. The IT owner approves operational readiness, engineering supplies behavioral comparisons, the suppliers document their support boundaries, and compliance reviews the safeguard evidence.
The decision could keep an engine for legacy messaging while shifting selected API workloads to a cloud service, or favor a single supported runtime if distributed troubleshooting creates unacceptable operational work. Neither conclusion follows from protocol support alone.
For teams weighing outside delivery help, a guide to healthcare integration engineering delivery models describes how managed and co-managed arrangements divide operational responsibility. Whatever the sourcing decision, require the architecture to show both the target state and the transitional state, because the transitional state determines whether the organization can absorb change without inheriting an unmanageable mix of old and new components.
Plan migration without losing message continuity
Begin with a behavioral inventory, not just an export of channel configuration. Record endpoints, message types, transformations, filters, acknowledgements, queues, credentials, certificates, consumers, schedules, alerts, and recovery procedures. Capture the runtime, Java dependencies, database dependencies, plugins, and custom libraries that affect execution.
Classify each interface as retain, rewrite, translate, or replace. Assign criticality according to downstream consequences and recovery needs, then select representative interfaces for validation. Don't use channel count alone as a measure of migration difficulty.
Build the equivalence evidence
Map each existing behavior to a target implementation. Include field-level transformations, terminology decisions, identity handling, routing conditions, error paths, and delivery semantics.
Use controlled test data and approved handling procedures for any production-derived samples. The acceptance package should cover:
Transformation results, comparing expected content and documenting intentional differences.
Acknowledgements, proving that acceptance and rejection occur at the required boundary.
Failure recovery, testing retries, queue restoration, duplicate handling, and reconciliation.
Security behavior, including rejected connections, expired credentials, and protected audit records.
Parallel validation should compare outputs without unintentionally executing the same downstream action twice. Use isolated destinations, shadow processing, or another explicitly controlled arrangement. Merely duplicating live delivery can invalidate the test and create operational consequences.
Assign cutover and rollback decisions
The customer's service owner should approve the migration window and acceptance criteria. Engineering owns the implementation evidence and rollback procedure; the vendor owns agreed product support; compliance reviews the documented controls and any unresolved risks.
Before cutover, establish:
Who can authorize the switch and who can stop it.
How queued and in-flight messages will be accounted for.
Which conditions trigger rollback.
Who restores the prior route and reconciles messages processed during the transition.
What evidence permits retirement of the previous runtime.
Support for integration into existing healthcare systems should be assessed against those deliverables. Require reproducible configurations, test results, operator instructions, and a clear handover rather than acceptance based only on a successful demonstration.
Keep the prior environment available according to the approved rollback plan. Decommission it only after the service owner accepts reconciliation results, operational monitoring, and recovery evidence.
Conclusion
The licensing change makes maintenance ownership, support boundaries, and migration evidence part of interface-engine selection. We would retain an existing release only under an explicit maintenance plan, evaluate supported engines against contractual responsibilities, and assess cloud services according to the processing work that remains outside them.
The strongest decision preserves necessary production behavior while making future operation supportable. Representative workload tests and controlled coexistence provide a better basis for that decision than a feature checklist.
Book a consultation with Ekipa's HealthTech engineers to review your interface inventory, support responsibilities, and migration acceptance criteria.
Frequently asked questions
Can we keep running the last open-source release?
Yes, continuing an earlier open-source deployment is distinct from adopting a later commercial release, as established in the licensing announcement above. Operational acceptance still requires a documented maintenance owner, risk assessment, and plan for dependencies and unresolved defects.
How does an interface engine differ from a FHIR server?
An interface-engine evaluation focuses on message transport, transformation, routing, acknowledgements, and recovery. A FHIR-server evaluation focuses on the required resource persistence and API behavior. A replacement architecture may need both responsibilities, even if one product packages them together.
What support evidence should we request from a supplier?
Request written escalation coverage, supported deployment boundaries, security-response procedures, and responsibility for recovery. Ask the supplier to explain how an incident moves from initial triage to a deployable correction. Confirm whether interface configuration and downstream reconciliation are included or remain customer responsibilities.
When is a community fork suitable?
A community fork is suitable for consideration when the organization can verify its maintenance process and operate the selected distribution responsibly. Evaluate released artifacts, dependency management, security handling, and compatibility with your tested interfaces. Source access alone doesn't establish operational readiness.
