Every health technology company, every hospital IT department, and every digital health startup eventually faces the same question: should we build our integration infrastructure with Mirth Connect, or should we buy a managed integration platform? The answer determines your architecture, your costs, your speed to market, and your operational burden for the next three to five years. Get it right and you build a competitive advantage. Get it wrong and you either bleed money on per-connection fees that compound with every new partner, or you drown in operational complexity that your team was never staffed to handle.
This is not a simple question, and anyone who gives you a simple answer is selling something. The right choice depends on your specific situation: how many integrations you need, how fast you need them, what your team looks like, how much you care about data sovereignty, and where you see your integration needs in three years. This guide lays out both options honestly, with real cost models, so you can make the decision with data rather than vendor pitches.
The Integration Dilemma
Healthcare integration is not optional. If you are building a health technology product, you need to exchange data with EHR systems, labs, pharmacies, imaging systems, and payers. According to the Office of the National Coordinator for Health IT (ONC), over 96 percent of hospitals have adopted certified EHR systems as of 2024. Your product does not exist in isolation. It exists in an ecosystem of systems that speak different languages: HL7v2, FHIR, DICOM, X12, proprietary APIs, flat files, and everything in between.
The average hospital runs 50 to 100 integration interfaces connecting its EHR to ancillary systems, according to HIMSS research. Each interface needs to be built, tested, deployed, monitored, and maintained. When an EHR vendor releases an update that changes a message format, every affected interface needs to be updated. When a new partner system comes online, a new interface needs to be built. Integration is not a one-time project. It is a permanent, ongoing operational responsibility.
You have two fundamental approaches: build the infrastructure yourself using an integration engine like Mirth Connect, or buy access to a managed platform that handles the infrastructure for you.
What "Build with Mirth" Actually Means
When you choose to build with Mirth Connect (now NextGen Connect Integration Engine), you are taking full responsibility for your integration infrastructure. Here is what that includes:
- Infrastructure: You provision and manage the servers (on-premise or cloud), the database (PostgreSQL or MySQL), the network configuration, SSL certificates, and firewall rules. For a production deployment with high availability, this means at minimum two Mirth instances behind a load balancer, a clustered database, and monitoring infrastructure.
- Software management: You install Mirth, configure JVM settings, manage upgrades, apply security patches, and handle licensing (commercial for v4.6+). You own the entire software stack.
- Integration development: You build every channel from scratch: source connectors, transformers, filters, destination connectors. You write the JavaScript transformation logic, build the channel design patterns, and create code template libraries for reusable functions.
- Testing and deployment: You build your own CI/CD pipeline for channel deployments, write test suites for your transformers, and manage environment promotion from development through staging to production. Our CI/CD guide for Mirth covers this in detail.
- Operations: You monitor channel health, manage message queues, troubleshoot failures, and handle on-call responsibilities. See our guide on production monitoring for Mirth.
The benefit is complete control. You own every byte of data, every transformation rule, every routing decision. You can customize any aspect of the platform. You can build complex, multi-step workflows that no managed platform supports. You are not locked into any vendor's pricing model or feature roadmap.
The cost is responsibility. Everything that breaks is your problem. Every security vulnerability is your patch. Every scaling challenge is your engineering effort.
What "Buy Managed" Actually Means
Managed integration platforms like Redox, Health Gorilla, and others provide integration as a service. You send data to their API, and they handle the translation, routing, and delivery to the destination system. Here is what that includes:
- Pre-built connections: Managed platforms maintain a network of existing connections to EHR systems, labs, and other healthcare organizations. When you need to connect to Epic, they already have the interface built and tested. You configure your side and they handle the rest.
- API-first architecture: You interact with a modern REST API, typically sending and receiving FHIR resources or custom JSON payloads. The platform handles translation to whatever format the destination system requires (HL7v2, proprietary, etc.).
- Managed infrastructure: They handle servers, databases, scaling, monitoring, security patches, and uptime. You get an SLA guaranteeing availability, typically 99.9 percent or better.
- Compliance coverage: Managed platforms handle much of the compliance burden: HIPAA Business Associate Agreements, SOC 2 certifications, encryption at rest and in transit, audit logging.
The benefit is speed and simplicity. You can have your first integration live in days to weeks rather than months. You do not need to hire integration engineers or manage infrastructure. You focus on your application while they handle the plumbing.
The cost is ongoing fees and less control. Per-connection pricing ranges from $500 to $2,000 per connection per month, and those fees compound as you add connections. You are constrained by the platform's capabilities and feature roadmap. If you need a custom transformation they do not support, you either wait for them to build it or work around it.
Cost Comparison: 3-Year Total Cost of Ownership
Cost is usually the decisive factor, so let us model it honestly. These numbers are based on US market rates as of 2026 and assume a mid-sized healthcare organization or health tech company.
Scenario A: Self-Hosted Mirth Connect
| Cost Category | Year 1 | Year 2 | Year 3 | 3-Year Total |
|---|---|---|---|---|
| Integration Engineers (2 FTE @ $150K) | $300,000 | $300,000 | $300,000 | $900,000 |
| Mirth Commercial License | $50,000 | $50,000 | $50,000 | $150,000 |
| Cloud Infrastructure (HA setup) | $48,000 | $48,000 | $48,000 | $144,000 |
| Initial Setup and Training | $75,000 | $0 | $0 | $75,000 |
| Monitoring and Tools | $12,000 | $12,000 | $12,000 | $36,000 |
| Total | $485,000 | $410,000 | $410,000 | $1,305,000 |
Per connection cost (assuming 30 connections): approximately $1,450/connection/month in Year 1, declining to $1,140/connection/month in subsequent years. At 50 connections: approximately $870/connection/month in Year 1, declining to $683/connection/month.
Scenario B: Managed Integration Platform
| Cost Category | Year 1 | Year 2 | Year 3 | 3-Year Total |
|---|---|---|---|---|
| Platform Fees (10 connections @ $1,000/mo) | $120,000 | $120,000 | $120,000 | $360,000 |
| Platform Fees (growth to 20 connections) | $0 | $60,000 | $120,000 | $180,000 |
| Platform Fees (growth to 30 connections) | $0 | $0 | $60,000 | $60,000 |
| Developer Time (API integration) | $50,000 | $25,000 | $25,000 | $100,000 |
| Setup and Onboarding | $25,000 | $0 | $0 | $25,000 |
| Total | $195,000 | $205,000 | $325,000 | $725,000 |
At 30 connections over three years, the managed platform costs $725,000 compared to Mirth's $1,305,000. The managed platform wins.
But here is where the math shifts. Scale the managed platform to 50 connections:
| Connections | Managed (3-year) | Mirth Self-Hosted (3-year) | Winner |
|---|---|---|---|
| 5 | $280,000 | $1,305,000 | Managed |
| 15 | $565,000 | $1,305,000 | Managed |
| 30 | $725,000 | $1,305,000 | Managed |
| 50 | $1,525,000 | $1,305,000 | Mirth |
| 75 | $2,275,000 | $1,405,000 | Mirth |
| 100 | $3,025,000 | $1,505,000 | Mirth |
The crossover point is approximately 40 to 50 connections. Below that, managed platforms are more cost-effective. Above that, self-hosted Mirth wins decisively because its costs are largely fixed (people and infrastructure) while managed platform costs scale linearly with connections.
Speed to First Integration
If your priority is getting your first EHR integration live as fast as possible, managed platforms have a significant advantage:
Managed Platform Timeline
- Week 1: Sign contract, receive API credentials, review documentation
- Week 2: Build API integration in your application, configure connection parameters
- Week 3: Testing with sandbox environment, go-live with first connection
Self-Hosted Mirth Timeline
- Weeks 1-2: Provision infrastructure, install and configure Mirth, set up database and monitoring
- Weeks 3-4: Hire or assign integration engineer, initial training if needed
- Weeks 5-6: Build first channel: source connector, transformer, destination, testing
- Weeks 7-8: End-to-end testing with partner system, security review
- Weeks 9-10: Go-live, initial monitoring and stabilization
The managed platform is three to four times faster to first integration. For startups trying to sign their first health system customer, or for hospitals with an urgent integration deadline, this speed difference can be decisive. Time to market has real revenue implications.
However, the speed advantage diminishes with each subsequent integration. Your second Mirth channel is built in days, not weeks, because the infrastructure exists and the team has experience. Your tenth channel might take hours. Meanwhile, each new managed platform connection still requires configuration, testing, and the same per-connection setup process.
Long-Term Flexibility and Vendor Lock-In
Vendor lock-in is one of the least discussed but most consequential factors in the build versus buy decision.
Mirth Connect Lock-In Risk: Low to Moderate
- Channel definitions are XML-based and can be exported and version-controlled
- Transformer logic is JavaScript, a universal language
- If you outgrow Mirth, your interface knowledge transfers to any integration engine
- Risk: dependency on Mirth-specific APIs and connector types. Migration to a different engine requires rebuilding channels, though the logic is portable
Managed Platform Lock-In Risk: Moderate to High
- Your application is built against the platform's proprietary API
- Switching platforms means rewriting every API integration point in your codebase
- Connection configurations and routing rules live in the platform's proprietary format
- Some platforms have exclusivity clauses in their contracts for certain EHR connections
- The more connections you have, the higher the switching cost
The irony is that organizations choose managed platforms to avoid complexity, but the lock-in they accept creates a different kind of complexity: the complexity of being dependent on a single vendor's pricing decisions, feature roadmap, and business viability.
Data Sovereignty and PHI Control
For many healthcare organizations, the most important factor is not cost or speed but data control. Where does Protected Health Information (PHI) flow, and who has access to it?
- Self-hosted Mirth: PHI stays within your infrastructure. Messages transit through your servers, stored in your database, encrypted by your keys. You control every aspect of data residency, retention, and access. For organizations subject to strict data governance requirements or operating in jurisdictions with data localization laws, this is non-negotiable.
- Managed platforms: PHI transits through the vendor's infrastructure. The vendor is a HIPAA Business Associate and maintains appropriate safeguards, but you are trusting a third party with your patients' data. Some managed platforms offer "data-through" architectures where messages pass through but are not stored, reducing the exposure. Others store messages for audit and replay purposes.
Both approaches can be HIPAA-compliant. The question is whether your organization's risk tolerance and governance requirements allow PHI to flow through third-party infrastructure. For many large health systems and organizations handling sensitive behavioral health, substance abuse, or reproductive health data, the answer is no.
The Middle Ground: Mirth Fully Managed by NextGen
NextGen Healthcare now offers Mirth Fully Managed, a cloud-hosted version of Mirth Connect where NextGen handles infrastructure, patching, scaling, and monitoring while you retain control over channel design and transformation logic. This middle ground offers several advantages:
- No infrastructure management burden
- Full Mirth channel design flexibility
- NextGen's operational expertise handling the platform
- SLA-backed availability
- Predictable subscription pricing
The trade-off is that you are still on Mirth's architecture (good for flexibility, but requires Mirth expertise) and you pay NextGen's managed service premium over self-hosting. It is a compelling option for organizations that want Mirth's capabilities without the operational burden.
Decision Matrix: When to Build vs When to Buy
Build with Mirth When:
- You have or plan more than 10 to 15 integration interfaces. The economics shift in favor of self-hosting above this threshold.
- You need complex, multi-step workflows. Message routing, transformation chains, conditional logic, fan-out to multiple destinations, and custom error handling are Mirth's strengths. See our deep dive on building a robust HL7 interface engine.
- PHI data sovereignty is non-negotiable. If PHI cannot leave your infrastructure, self-hosting is the only option (or Mirth Fully Managed with appropriate data residency controls).
- You have or can hire integration engineering talent. Mirth requires skilled engineers. If you can attract and retain them, the platform rewards expertise with extraordinary flexibility.
- Your protocol requirements are diverse. HL7v2, FHIR, DICOM, X12, database, and file-based interfaces in a single platform. For organizations navigating the HL7 vs FHIR transition, Mirth handles both.
- Long-term cost optimization matters more than short-term speed.
Buy Managed When:
- You need fewer than 10 integrations. The managed platform's higher per-connection cost is offset by dramatically lower fixed costs.
- Speed to first integration is critical. If you need to be live in weeks rather than months, managed platforms win.
- You have no integration engineering expertise and do not want to build it. Your team is application developers, not integration engineers. The managed platform abstracts the complexity you cannot handle.
- Your integrations are primarily FHIR-based. If you are only consuming FHIR APIs and do not need HL7v2 or other legacy protocols, the overhead of running Mirth may not be justified.
- You are a startup that needs to prove product-market fit before investing in infrastructure. The managed platform lets you validate the business before committing to operational complexity.
Real-World Decision Scenarios
Scenario 1: Health System with 80 Interfaces
A 500-bed hospital with 80 existing HL7v2 interfaces and plans to add FHIR APIs for patient portal and third-party app integrations. They have a team of three integration engineers. Decision: Build with Mirth. The economics are overwhelming at this scale. Managed platform fees for 80 connections would exceed $1 million per year. Their existing team has the skills, and they need the complex workflow capabilities for multi-step message routing between their EHR, lab, pharmacy, and radiology systems.
Scenario 2: Digital Health Startup with 3 EHR Integrations
A Series A startup building a patient engagement platform. They need to connect to Epic, Cerner, and Athenahealth to pull patient demographics and appointment data. Their team is five application developers with no healthcare integration experience. Decision: Buy managed. At three connections, the math favors managed platforms. More importantly, the startup cannot afford to hire a specialized integration engineer and wait two months for the first integration. They need to be live in three weeks to meet their pilot commitment.
Scenario 3: Healthcare Analytics Company Scaling Rapidly
A growth-stage company processing clinical data from 25 health system partners, with plans to reach 60 within 18 months. They currently use a managed platform but are concerned about costs at scale. Decision: Migrate to Mirth. They are past the crossover point and heading further into territory where self-hosting saves significant money. Their managed platform costs are projected to exceed $1.5 million per year at 60 connections. A well-staffed Mirth deployment would cost half that. The migration is painful but the three-year savings justify it.
Migration Considerations
If you start with one approach and need to switch, here is what to expect:
Managed to Mirth Migration
Typical timeline: 3 to 6 months. The hardest part is rebuilding the connection logic that the managed platform abstracted. You need to understand the actual message formats and protocols each partner system uses, which the managed platform may not have exposed to you. Our guide on migration strategies covers the process in detail.
Mirth to Managed Migration
Typical timeline: 2 to 4 months. Easier in some ways because you already understand your integration requirements in detail. The main work is rewriting your application's integration points to use the managed platform's API instead of Mirth's channels.
The Bottom Line
There is no universally correct answer to build versus buy. The right choice depends on your scale, your team, your timeline, your data governance requirements, and your growth trajectory. The worst decision is the default decision: choosing a managed platform because "it's easier" without modeling the three-year cost, or choosing Mirth because "it's cheaper" without accounting for the staffing and operational burden.
Do the math for your specific situation. Model the costs at your current scale and at your projected scale in three years. Assess your team's capabilities honestly. Consider your data governance requirements carefully. Then decide. And build in a review point at 18 months, because the right answer today may not be the right answer as your integration portfolio evolves.
The organizations that get integration right are not the ones that picked the "best" platform. They are the ones that picked the right platform for their situation and invested appropriately in making it work. Whether that is Mirth Connect, a managed platform, or a hybrid approach, the investment in getting the decision right pays for itself many times over.
Need expert help with healthcare data integration? Explore our Healthcare Interoperability Solutions to see how we connect systems seamlessly. We also offer specialized Healthcare Software Product Development services. Talk to our team to get started.
Frequently Asked QuestionsCan we start with a managed platform and migrate to Mirth later?
Yes, and this is a common strategy, especially for startups. Start with a managed platform to get your first 5 to 10 integrations live quickly, prove your product-market fit, and generate revenue. Then migrate to Mirth when you reach the crossover point (typically 15 to 20 connections) where self-hosting becomes more cost-effective. Plan for a 3 to 6 month migration window and maintain both systems in parallel during the transition. The key is to document your integration requirements thoroughly from the start so the migration is a known quantity, not a discovery project.
How do we account for the risk of a managed platform vendor going out of business?
This is a real risk in the health tech space, where many integration platforms are venture-backed startups. Mitigation strategies include: choosing vendors with established revenue and customer bases (Redox has been operating since 2014, for example), negotiating source code escrow provisions in your contract, maintaining detailed documentation of all your integration specifications independent of the platform, and avoiding features that are deeply proprietary and would be hard to replicate. Having an exit strategy is not pessimism; it is good engineering.
What about open-source alternatives to Mirth Connect since v4.6 went commercial?
The open-source Mirth Connect 4.5.2 remains available and functional. Community forks may emerge, though none have gained significant traction as of early 2026. Other open-source integration engines exist (Apache Camel, for example) but lack Mirth's healthcare-specific features like native HL7v2 parsing, MLLP support, and healthcare message templates. For organizations committed to open source, the best approach is running 4.5.2 with a plan to either maintain it internally or migrate to a commercial option when necessary. True interoperability requires tools built for healthcare's unique requirements.
How does the build vs buy calculus change with Mirth Fully Managed?
Mirth Fully Managed shifts the crossover point. Because it eliminates infrastructure management costs and reduces the staffing requirement (you still need channel developers but not infrastructure engineers), the break-even point with managed platforms moves lower, perhaps to 10 to 15 connections instead of 40 to 50. However, you still need Mirth expertise to build and maintain channels, so it does not fully replicate the managed platform's "no integration expertise needed" benefit. It is best suited for organizations that want Mirth's flexibility without the DevOps burden.
Should we factor in the CMS Interoperability and Prior Authorization Final Rule when making this decision?
Absolutely. The CMS rules requiring payers to implement Patient Access, Provider Directory, and Prior Authorization APIs using FHIR R4 by 2026 are driving FHIR adoption across the industry. If your integration roadmap is primarily FHIR-based, managed platforms that specialize in FHIR may be more appropriate. If you need to bridge FHIR with existing HL7v2 infrastructure (which most health systems do), Mirth's multi-protocol capability gives it an edge. The regulatory landscape favors platforms that can handle both standards simultaneously.
