OIE vs BridgeLink vs Commercial Mirth Connect: 2026 Comparison

The Mirth Connect ecosystem has fractured into three distinct paths, and every healthcare IT team running Mirth-based integrations needs to choose one. Since NextGen Healthcare moved Mirth Connect to a commercial-only license in March 2025, two open-source forks have continued the MPL 2.0 lineage: the Open Integration Engine (OIE), a community-driven vendor-neutral fork hosted at the Eclipse Foundation, and BridgeLink, an Innovar Healthcare–led fork. Meanwhile, NextGen continues to develop commercial Mirth Connect under its new licensing model.

Each platform has inherited the core Mirth Connect DNA: the channel-based architecture, the JavaScript transformer engine, the multi-protocol connector framework, and the Administrator console. The two open-source forks diverge mostly in community, release cadence, and the services ecosystem around each project, not in core features. This guide provides a detailed, side-by-side comparison to help you make the right choice for your organization.

That held for the first releases in 2025. Through 2026 the platforms underneath the shared channel format began to drift apart: BridgeLink moved to calendar versions with Jetty 12 and Java 21 recommended, OIE 4.6.0 raised its floor to Java 17, and NextGen’s commercial line reached 4.7.x. Channels still move between them, but servers, drivers and admin tooling no longer match one for one. Where the platforms have diverged lists the changes, and the upgrade gotchas under Migration Considerations cover what they break.

For background on the licensing change that created this situation, see our companion article: Mirth Connect Alternatives in 2026.

Where Each Platform Stands in October 2026

Release status as of October 11, 2026. The last column tracks the three flaws in CISA advisory ICSMA-26-253-01, published September 10, 2026, which affect every Mirth Connect build up to 4.7.1 and OIE 4.6.0. Our Mirth Connect vulnerabilities guide explains the flaws and how to check your exposure.

OIE 4.6.0 and OpenShare Engine 4.6.0-7 both report version 4.6.0, so check which build you installed rather than the number. BridgeLink’s 26.x numbers start with the year (26.3, 26.6 and 26.9 all shipped in 2026), so they cannot be compared with Mirth Connect’s 4.x numbers.

The Three Platforms at a Glance

Before diving into the feature comparison, here is a brief overview of each platform and the organization behind it.

OIE (Eclipse Open Integration Engine)

OIE is the community fork of Mirth Connect, hosted at the Eclipse Foundation with contributions from a multi-vendor open-source community. It was created to preserve the open-source healthcare integration engine that thousands of healthcare organizations relied on, explicitly positioned as vendor-neutral.

Philosophy: Continue the open-source Mirth Connect legacy. Community-driven, vendor-neutral development. No licensing fees. Transparent governance under the Eclipse Development Process, with a public committer list and roadmap.

Organization: OIE is an Eclipse Foundation project under the Eclipse Technology PMC, developed by a group of committers. Development happens openly on GitHub. A broad list of independent vendors (including Saga IT, NovaMap Health, Zen Healthcare IT, Bright Code Company, Meditecs, Doctible, MyDirectives, and others) offers commercial support and professional services around the platform.

First stable release: Mid-2025, based on the Mirth Connect 4.5.2 codebase.

Latest release: v4.6.0, July 9, 2026. It requires Java 17 and removed the bundled Xerces XML parser. The project has merged fixes for the September 2026 security advisory but has not released them yet; see the status table above.

BridgeLink

BridgeLink is an open-source fork of Mirth Connect maintained by Innovar Healthcare. Like OIE, it is free under the MPL 2.0 license and carries the Mirth Connect codebase forward. The two forks started from the same code and still share the channel format; the main distinction has been governance and community structure, and since 2026 the platforms underneath have started to differ as well (details below). OIE is a vendor-neutral community fork hosted at the Eclipse Foundation with contributions and services from multiple independent vendors. BridgeLink is led primarily by Innovar Healthcare, with paid services available from Innovar Healthcare for teams that want vendor backing on top of the open-source engine.

Philosophy: Continue the open-source Mirth Connect lineage under Innovar Healthcare’s stewardship, with paid services from Innovar Healthcare as the primary commercial path for teams that want vendor backing.

Organization: Innovar Healthcare, the company behind BridgeLink. Development happens publicly on GitHub. For the canonical list of BridgeLink releases, supported services, and Innovar Healthcare’s commercial offerings, see innovarhealthcare.com. Vendor product details change and the authoritative source is Innovar Healthcare itself.

License: the engine is MPL 2.0, with source on GitHub. The browser-based BridgeLink WebAdmin console is source-available under the Business Source License, which allows production use with BridgeLink.

Versions: BridgeLink’s first releases kept Mirth-style numbers, from 4.5.3 in March 2025 to 4.6.1 in January 2026. In April 2026 Innovar Healthcare switched to calendar versions: 26.3.0 (April 7), 26.6.0 (July 22), 26.6.1 (September 16, a security patch) and 26.9.0 (October 1, 2026), the current release. The 26.x line runs on Jetty 12, and Java 21 is recommended for every server.

What ships with it: Git-backed version history built into the core (change tracking, diffs and rollback for channels, code templates and global scripts), plus OIDC sign-on, Message Trends and Dynamic Lookup Gateway plugins. Since 26.6.0, BridgeLink WebAdmin gives a browser-based alternative to the Java Administrator, and 26.9.0 removed the older dashboard that used to be bundled with the server. Innovar publishes official container images of each release, including Docker Hardened Images.

Around the engine: Innovar Healthcare sells per-server subscriptions that add features such as advanced access control and identity-provider sign-on, support plans, BridgeLink Health Check assessments, training with a BridgeLink Essentials certification, and BridgeLink editions on AWS Marketplace (Developer, Standard and Enterprise). Its Fleet product manages many BridgeLink instances from one console, covering health, configuration drift and alert routing.

Commercial Mirth Connect 4.6+

Commercial Mirth Connect is the continuation of the original Mirth Connect product under NextGen Healthcare’s new commercial-only licensing model. Version 4.6 was the first release under the new license.

Philosophy: Sustain and enhance the original Mirth Connect product with commercial investment. Vendor-backed support and guaranteed updates.

Organization: NextGen Healthcare, a Thoma Bravo–backed healthcare technology company (formerly NASDAQ: NXGN; taken private in November 2023) that acquired Mirth Connect through a series of corporate transitions: WebReach Inc. (2006) renamed itself Mirth Corporation in 2009, Quality Systems Inc. acquired Mirth Corporation in 2013, and Quality Systems rebranded as NextGen Healthcare in 2018.

First commercial-only release: Mirth Connect 4.6, which arrived with the license change NextGen announced on March 19, 2025. The commercial line has since reached 4.7.x, and 4.7.2 is the release CISA’s September 2026 advisory names as the fix for three flaws that reach every earlier build.

Licensing: NextGen sells Mirth Connect in three license tiers, Enterprise, Gold and Platinum, as a flat annual fee for each production server, and publishes no prices. Source for new releases is no longer public.

Feature Comparison

This is the comprehensive comparison table. We have organized it into categories that matter most to integration teams making a platform decision.

Core Integration Capabilities

All three platforms share the same core connector framework inherited from Mirth Connect. OIE and BridgeLink both extend that framework through their community ecosystems, while NextGen maintains its own roadmap of connector improvements for commercial Mirth Connect.

Where the Platforms Have Diverged

Every row in the table above still holds for channel work, because all three read the same channel format. Underneath the channels, the platforms stopped being copies of each other during 2026:

• BridgeLink 26.x. Calendar versions since April 2026 (26.3.0, 26.6.0, 26.6.1, then 26.9.0 on October 1). The server moved from Jetty 9.4 to Jetty 12. Java 21 is recommended for every server and required when the server uses the built-in Derby database; servers on an external database can stay on Java 17. Version history is built into the core, and the product ships OIDC sign-on, Message Trends and Dynamic Lookup Gateway plugins. Browser administration moved to the standalone WebAdmin console, and 26.9.0 removed the dashboard that used to be bundled with the server. 26.9.0 also retired the jTDS driver, which ended Sybase support, and it runs the Linux service as a dedicated non-root user. Around the engine, Innovar Healthcare offers Fleet for managing many instances and publishes Docker Hardened Images of each release.
• OIE 4.6.0. The Eclipse project’s July 2026 release requires Java 17 and removed the bundled Xerces and xml-apis libraries, so custom code that imports org.apache.xerces classes directly has to move to the standard javax.xml.parsers APIs. Logins became case-insensitive. Its next release will carry the merged security fixes.
• Commercial Mirth Connect 4.6 and later. NextGen no longer publishes source for new releases, so its changes are visible only through its release notes and customer portal. The line has reached 4.7.x, and NextGen sells it with its own extensions in Enterprise, Gold and Platinum tiers.

For a team choosing between the two forks, the practical effect is that a BridgeLink server and an OIE server now differ in Java requirements, bundled drivers and admin tooling, even though the channels you deploy to them are the same.

Deployment and Operations

Deployment options are broadly similar across OIE and BridgeLink. Both are self-managed open-source forks. Innovar Healthcare offers paid services for teams that want vendor backing. See innovarhealthcare.com for the current offering catalog. Commercial Mirth Connect adds NextGen’s clustering feature as its main deployment-layer differentiator.

Monitoring and Observability

All three platforms inherit Mirth Connect’s built-in dashboard. Teams on OIE and BridgeLink typically pair it with external tools (Prometheus/Grafana, ELK/Splunk, or Datadog). Commercial Mirth Connect adds NextGen’s alerting and audit add-ons. Innovar Healthcare offers paid services that can layer on top of the open-source engine for teams that want vendor backing. BridgeLink also ships a Message Trends plugin for time-series message statistics, and Innovar’s Fleet console watches many BridgeLink instances at once and routes their alerts to Slack, Microsoft Teams or PagerDuty.

Whichever open-source engine you pick, our OpenShare integration platform works across OIE, BridgeLink, and open-source Mirth Connect: operate your servers, share channels and data with partner organizations, and monitor your whole fleet from one browser console.

Security

All three platforms support TLS, LDAP, and the encryption capabilities inherited from Mirth Connect. The September 2026 advisory is the first real measure of how fast each one patches, and the record says more than any promised SLA:

• August 5, 2026. By this date NextGen had confirmed fixes for all three flaws in its commercial releases, according to the disclosure timeline of the researcher who reported them.
• September 10. CISA published advisory ICSMA-26-253-01, naming commercial Mirth Connect 4.7.2 as the fix. The same day, the researcher published working proof-of-concept code.
• September 14. Saga IT shipped OpenShare Engine 4.6.0-7, our open-source build of OIE 4.6.0, with all three fixes.
• September 16. Innovar Healthcare shipped BridgeLink 26.6.1 with the same three fixes, as a free public release.
• September 22 to 29. OIE merged its three fixes. As of October 11, 2026, no OIE release includes them, and no release date has been announced.

The flaws reach every Mirth Connect build up to and including 4.7.1, which covers every open-source release, and they reach OIE 4.6.0 as well. Our Mirth Connect vulnerabilities guide explains how to tell whether you are exposed and what to do about it. Contractual patch terms are a separate question: NextGen’s come with a commercial agreement, Innovar Healthcare sells support plans for BridgeLink, and OIE users can buy support from an independent partner such as Saga IT.

FHIR and Interoperability Standards

For organizations doing significant FHIR work (payer API compliance, CMS-0057-F implementation), the Mirth Connect–lineage platforms are fine for inbound/outbound FHIR via channels, but none of them ship a full FHIR server. Teams that need a FHIR facade, SMART on FHIR, Bulk FHIR, or Da Vinci IG support typically pair their integration engine with a dedicated FHIR server (HAPI FHIR, Smile CDR, Microsoft Azure FHIR, Google Cloud Healthcare API, etc.). For HL7 v2, DICOM, or X12 integration, all three Mirth-lineage platforms serve equally well.

Licensing and Cost

Both OIE and BridgeLink are free MPL 2.0 projects; your only engine cost is infrastructure (typically $200–$500/month for a single cloud instance). Organizations running BridgeLink who want vendor-backed services can buy those directly from Innovar Healthcare (BridgeLink Health Check, AWS Marketplace–activated support, certification, custom plugin development), but the platform itself has no licensing fee. Commercial Mirth Connect runs in the low-to-mid five figures annually for a single instance with standard support and scales up from there. For multi-instance deployments, the license-cost gap between commercial Mirth and either open-source fork compounds significantly. Our guide to Mirth Connect alternatives puts three-year cost figures on these three paths and on non-Mirth engines such as Qvera, Rhapsody and Cloverleaf.

Community and Support

OIE and BridgeLink both offer community support by default. Organizations running BridgeLink can purchase vendor-backed services (including support activated through AWS Marketplace) from Innovar Healthcare. Commercial Mirth Connect offers tiered vendor support from NextGen with defined SLAs. We recommend asking for customer references specific to support experiences before committing to any paid service tier.

BridgeLink vs Mirth Connect

BridgeLink began as a fork of open-source Mirth Connect 4.5.2, so a BridgeLink server still works like Mirth Connect: the same Administrator, the same channel model, the same REST API. What separates it from NextGen’s commercial Mirth Connect is who controls it and on what terms.

Channels built on open-source Mirth Connect move to either one. Moving between BridgeLink and commercial Mirth Connect is less certain in both directions: each side has added features since the fork, and a channel that depends on one of them needs it on the target server, so test the move on a non-production server first. What each option costs over three years, next to OIE and non-Mirth engines, is in the pricing section of our Mirth Connect alternatives guide.

Migration Considerations

Whichever platform you choose, migration from your existing Mirth Connect instance is the immediate practical concern. Here is what to plan for.

Channel Compatibility

All three platforms maintain compatibility with Mirth Connect channels at the XML level. You can export channels from one platform and import them into another. The underlying channel model (sources, destinations, transformers, filters, scripts) is the same across all three.

That holds for channels from open-source Mirth Connect (through 4.5.2) moving to OIE or BridgeLink. We have not verified exports from NextGen’s commercial 4.6 and later releases going back into either fork, and a channel that uses a commercial extension will not run there, so import commercial exports into a test server before you plan a cutover.

However, there are nuances:

• Global scripts and code templates: These migrate cleanly across all three platforms.
• Custom Java libraries: If your channels depend on custom JAR files in Mirth’s custom-lib directory, those JARs work on all three platforms (assuming Java version compatibility).
• Commercial plugins: If you use NextGen’s commercial plugins (advanced alerting, clustering), those plugins are proprietary and will not run on either open-source fork (OIE or BridgeLink). If you are migrating to OIE or BridgeLink, you need to replace commercial plugin functionality with community alternatives, vendor-provided plugins, or custom solutions.
• Database schema: All three platforms use a compatible database schema for the core channel and message tables. You can point a new installation at your existing database. However, test this thoroughly in a non-production environment first, and always maintain a backup.

Upgrade Gotchas in the 2026 Releases

Channel XML moves cleanly. These platform changes are what break upgrades in practice:

• jTDS is gone from BridgeLink 26.9.0. A channel that uses a jdbc:jtds:sqlserver:// connection string fails to deploy until you switch it to the Microsoft driver (jdbc:sqlserver://host:port;databaseName=db), and nothing rewrites the strings for you. Sybase connections have no replacement driver. The new driver also encrypts SQL Server connections and checks the server certificate by default, so a self-signed certificate that worked before will be refused.
• Derby needs Java 21 on BridgeLink. From 26.6.1, a server on the built-in Derby database stops at startup on Java 17. Servers on PostgreSQL, MySQL, SQL Server or Oracle can stay on Java 17, and Innovar Healthcare describes Derby as meant for evaluation and testing only.
• BridgeLink’s web dashboard moved out. 26.9.0 no longer ships the bundled /webadmin dashboard, and browser administration runs in the separate WebAdmin console instead. An upgrade leaves the old webadmin.war in place, so delete it yourself.
• XSLT steps refuse external DTDs. The fixes for the September 2026 advisory change how XSLT steps treat a message whose DOCTYPE points to an external DTD or entity (a <!DOCTYPE ... SYSTEM "..."> line): BridgeLink 26.6.1 and later and OpenShare Engine 4.6.0-7 fail the step, and OIE’s merged fix errors on any message that carries a DOCTYPE in that step. BridgeLink also blocks stylesheets that pull in other files through xsl:import, xsl:include or document(), which OpenShare Engine leaves working. Some older CDA and HL7 v3 feeds carry such a line, so test them before you cut over.
• OIE 4.6.0 needs Java 17 and drops Xerces. Code templates or custom JARs that import org.apache.xerces classes directly have to move to javax.xml.parsers before you upgrade.

Pointing a new installation at an existing database works within the open-source line, but BridgeLink’s 26.x releases run their own schema migrations on first start, so take a backup first. We have not verified pointing either fork at a database that a commercial 4.6 or later server has upgraded.

Migration Workflow with MirthSync

The cleanest migration approach uses MirthSync to extract your channel configurations into version-controlled files and then deploy them to your target platform. It works between the open-source engines: open-source Mirth Connect through 4.5.2, OIE and BridgeLink. We have not been able to test MirthSync against NextGen’s commercial releases, so if commercial Mirth Connect is your source or your target, use its own export and import and check the result on a test server.

Here is a step-by-step migration workflow:

# Step 1: Pull all configurations from your existing Mirth Connect instance
mirthsync -s https://current-mirth:8443/api \
  -u admin -p admin \
  --include-configuration-map \
  pull

# Step 2: Review what was pulled
ls -la Channels/ CodeTemplates/ GlobalScripts/

# Step 3: Commit to Git for a clean baseline
git init
git add -A
git commit -m "Baseline: Mirth Connect 4.5.2 channel export"

# Step 4: Push configurations to your new platform (OIE or BridgeLink)
mirthsync -s https://new-platform:8443/api \
  -u admin -p admin \
  --include-configuration-map \
  push

# Step 5: Verify channel deployment
# Log into the new platform's Administrator console and verify all channels imported correctly

This workflow gives you:

• A complete Git history of your channel configurations.
• The ability to diff between your old and new environments.
• A rollback point if anything goes wrong.
• A foundation for ongoing CI/CD with your new platform.

Database Migration

If you want to preserve message history (not just channel configurations), you have two options:

1. Point the new platform at your existing database. This preserves all message history but couples your new platform to your old database. Test compatibility thoroughly.
2. Start fresh with a new database. This is cleaner and avoids compatibility risks, but you lose message history. If you need to retain historical messages for compliance, archive them separately before migrating.

For most organizations, we recommend option 2 (fresh database) with a separate message archival strategy for compliance. Historical messages can be exported from the old database and stored in long-term archival storage (S3, Azure Blob Storage, etc.) without being in the active integration engine database.

Custom Plugin Migration

If your Mirth Connect deployment uses custom plugins (developed in-house or by third parties), migration requires additional planning:

• OIE: Custom plugins built against the Mirth Connect Plugin API should work with minimal modification. The plugin API is preserved in OIE. Test each plugin in a staging environment. OIE 4.6.0 requires Java 17 and no longer bundles Xerces, so rebuild and retest any plugin that depends on either.
• BridgeLink: Custom plugins built against the Mirth Connect Plugin API should work with minimal modification. The plugin API is preserved in BridgeLink’s fork. Innovar Healthcare also publishes its own plugins for BridgeLink and offers custom plugin development as a service. On the 26.x line, check that each plugin lists your BridgeLink version among the versions it supports, and that it runs on Jetty 12 and on the Java version you choose.
• Commercial Mirth 4.6+: Custom plugins from 4.5.2 should be forward-compatible with 4.6+, though testing is still required.

Estimated Migration Effort

These estimates include the technical migration work but not the organizational work (procurement, change management, training). Add time for those activities based on your organization’s processes.

Decision Framework: Which Should You Choose?

Here is a structured decision framework to help you evaluate the three platforms against your organization’s specific needs.

Choose OIE If:

• Budget is a primary constraint. OIE has zero licensing costs. For organizations running multiple instances, the savings over commercial options can be substantial.
• You have strong in-house Mirth expertise. Your team can troubleshoot issues without vendor support, contribute to the community, and manage the platform independently.
• You value open-source principles. Transparency in development, community governance, and the freedom to inspect, modify, and redistribute the code matter to your organization.
• Your integrations are primarily HL7 v2, DICOM, and X12. OIE’s core integration capabilities are fully mature for these standards, and (like any Mirth-lineage platform) the FHIR support is suitable for channel-based work rather than running a full FHIR server.
• You want the lowest-risk migration path. OIE is the most compatible with existing Mirth Connect deployments. The migration is straightforward and well-documented. See our OIE consulting and migration services for the engagement model.
• You are a health IT vendor embedding an integration engine. The open-source license allows you to bundle OIE in your product without per-instance licensing fees.

Choose BridgeLink If:

BridgeLink and OIE are both free, MPL 2.0 forks of Mirth Connect that share a channel format, so for channel work the practical difference is which fork’s community you want to align with. Because BridgeLink is MPL 2.0, any independent vendor (including Saga IT) can offer services on top of it; you are not locked to a single vendor for support. The narrow reasons to pick BridgeLink over OIE:

• You specifically want Innovar Healthcare as your integration partner. Innovar Healthcare leads BridgeLink’s development. If you’ve already engaged Innovar Healthcare or want them as your primary vendor, BridgeLink keeps your platform and your vendor aligned.
• You want a fork that’s actively shaped by a single vendor. Some teams prefer the predictability of a fork led by one company over a multi-vendor committee. BridgeLink fits that model; OIE intentionally does not.
• You want what BridgeLink has built in since 2026. Git-backed version history in the core, the browser-based WebAdmin console, Fleet for many instances, and Innovar’s editions on AWS Marketplace. On OIE, our OpenShare platform adds a browser console and fleet monitoring, and the MirthSync Plugin adds Git inside the Administrator.

For every other scenario (vendor optionality, multi-vendor support ecosystem, open governance), OIE delivers the same channel-level result with a broader community behind it.

Choose Commercial Mirth Connect 4.6+ If:

• You want the simplest possible migration. Upgrading from open-source Mirth Connect to commercial Mirth Connect 4.6+ is a standard version upgrade with minimal risk. Our Mirth Connect services cover both the version-upgrade path and the security patching that older installations urgently need. Builds older than 4.4.1 carry CVE-2023-43208, which is on CISA’s Known Exploited Vulnerabilities catalog, and every build up to and including 4.7.1 carries the three flaws in CISA’s September 2026 advisory, which 4.7.2 fixes (details).
• You are already in the NextGen ecosystem. If you use NextGen’s EHR, practice management, or other products, staying with their integration engine keeps your vendor relationship consolidated.
• You want a single commercial vendor backing the core engine. Commercial Mirth Connect provides NextGen-maintained source code, vendor-issued security patches with SLAs, and commercial add-ons (advanced alerting, clustering) that open-source forks do not include out of the box.
• Your team is trained on Mirth Connect and you want continuity. The Administrator console, channel editor, and operational workflows are identical to what your team already knows.
• You need clustering for high availability. NextGen’s commercial clustering feature has been production-tested for years.

Decision Matrix

Score each factor 1-5 based on how important it is to your organization, then see which platform scores highest:

Multiply each platform’s score by your weight for that factor, then sum the results. The platform with the highest weighted score is your best fit. Because OIE and BridgeLink are both MPL 2.0 Mirth Connect forks with the same channel format, most of the scoring differences come down to community breadth, which vendor you want to buy services from, and the platform changes each has made since 2026.

MirthSync on OIE and BridgeLink

One of the practical benefits of the Mirth Connect ecosystem’s shared DNA is that MirthSync works the same way on open-source Mirth Connect through 4.5.2, OIE and BridgeLink. MirthSync connects to the standard Mirth REST API, which both open-source forks preserve. We have not been able to test it against NextGen’s commercial releases (4.6 and later), so treat commercial Mirth Connect as untested and try MirthSync on a non-production server before you rely on it there.

MirthSync CLI

The MirthSync CLI is the core command-line tool for pulling and pushing channel configurations. It works with OIE, BridgeLink and open-source Mirth Connect through 4.5.2 without any configuration changes. Just point it at the target platform’s API endpoint.

MirthSync Plugin

The MirthSync Plugin installs directly into the Mirth/OIE Administrator console, providing Git integration from within the GUI. It works with OIE and open-source Mirth Connect through 4.5.2. BridgeLink compatibility depends on the Administrator console version; contact us for details.

MirthSync VS Code Extension

The MirthSync VS Code Extension provides IDE-based channel management and is available on the VS Code Marketplace. It connects to any server that speaks the standard Mirth REST API, including OIE, BridgeLink and open-source Mirth Connect through 4.5.2.

CI/CD Across Platforms

Whichever open-source platform you choose, MirthSync enables CI/CD workflows that do not depend on the engine. A GitHub Actions workflow that deploys channels to production works identically whether your production environment runs OIE, BridgeLink, or open-source Mirth Connect:

name: Deploy Channels to Production

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy channels via MirthSync
        run: |
          java -jar mirthsync.jar \
            -s ${{ secrets.MIRTH_API_URL }} \
            -u ${{ secrets.MIRTH_USER }} \
            -p ${{ secrets.MIRTH_PASS }} \
            push

      - name: Verify deployment
        run: |
          # Hit the platform's API to verify channels are deployed and running
          curl -k -u ${{ secrets.MIRTH_USER }}:${{ secrets.MIRTH_PASS }} \
            "${{ secrets.MIRTH_API_URL }}/channels/statuses" | \
            jq '.list.dashboardStatus[] | {name: .name, state: .state}'

This CI/CD approach works the same on OIE, BridgeLink and open-source Mirth Connect. The MIRTH_API_URL secret points to whichever of them you are running, so switching between them does not require changing your CI/CD pipeline, only the target URL.

Real-World Deployment Patterns

Based on our work with healthcare organizations navigating this transition, here are the three deployment patterns we see most frequently. If you just want to spin up one of these locally to evaluate it, see our 2026 Docker quickstart. Five minutes to a running stack, no installer wizard.

Pattern 1: OIE across all environments. The most common pattern for small to mid-size organizations. OIE runs in dev, staging, and production, with MirthSync providing CI/CD. Cost is infrastructure only, typically $500-2,000/month depending on scale.

Pattern 2: BridgeLink across all environments, with Innovar Healthcare services. Organizations that have engaged Innovar Healthcare for integration work often standardize on BridgeLink and layer Innovar Healthcare’s paid services (BridgeLink Health Check, AWS Marketplace support, certification) on top. The engine itself is still free under MPL 2.0, so cost scales with the services purchased rather than per-instance licensing.

Pattern 3: Commercial Mirth Connect everywhere. Organizations already in the NextGen ecosystem often standardize on commercial Mirth Connect across all environments. This provides a consistent experience and simplifies vendor support interactions.

Next Steps

Choosing between OIE, BridgeLink, and commercial Mirth Connect is a significant decision that affects your integration infrastructure for years to come. Here is how to move forward:

1. Assess your current state. Inventory your Mirth Connect instances, channels, custom plugins, and integration patterns. Understand what you have before choosing where to go.
2. Score the decision matrix. Use the weighted decision matrix above to quantify which platform best fits your priorities.
3. Run a proof of concept. Set up the leading candidate in a test environment, migrate a representative subset of channels, and validate that everything works as expected.
4. Plan your migration. Use MirthSync to export your current configuration, set up your target environment, and develop a testing plan.
5. Execute with support. Whether you handle the migration in-house or engage a consulting partner, allocate adequate time for testing and validation.

Our Mirth Connect consulting team has hands-on experience with all three platforms and has guided organizations through dozens of migrations. We also offer specialized services for the Open Integration Engine, including deployment, optimization, and ongoing support. If the move includes rebuilding HL7 v2 interfaces, our HL7 integration services team handles interface design, testing, and cutover.

Need help choosing or migrating? Contact us for a free platform assessment and we will help you evaluate your options based on your specific integration landscape, budget, and operational requirements.