Self-Hosted vs Managed Healthcare Integration: A Decision Guide
Last updated: November 2026
We get this question on nearly every engagement: "Should we run our own engine or use Redox/Health Gorilla/Particle?"
The answer is almost always "it depends on where you are today and where you will be in 18 months." Here is the framework we walk through.
The two models
Self-hosted means you deploy an integration engine (MedHook, Mirth Connect, HAPI FHIR, Rhapsody) on your own infrastructure — a cloud VPC, on-premise servers, or an air-gapped environment. You own the data path, the operations, and the transforms.
Managed means a vendor (Redox, Health Gorilla, Particle Health) runs the integration platform in their cloud. You call their API. They handle EHR connections, uptime, credential management, and message translation.
When managed is the right starting point
You have fewer than 5 EHR connections
At low connection counts, managed platforms are often cheaper than the engineering time to set up and operate self-hosted infrastructure. The per-connection fee is the cost of not hiring an integration engineer.
Speed to pilot is existential
If a hospital partner says "have data flowing in two weeks or we go with someone else," a managed platform can meet that deadline. Self-hosted requires infrastructure setup, adapter configuration, connection testing, and credential management. That is a 2-6 week process even with experienced engineers.
Your team has zero infrastructure experience
A five-person startup with no DevOps capability should not be managing Docker containers and monitoring MLLP connections. The opportunity cost of diverting an engineer from product work to integration operations is usually higher than the managed platform fee.
When self-hosted becomes necessary
Your data cannot leave your infrastructure
Government healthcare (VA, DoD, state Medicaid), organizations with strict data residency requirements, and any contract that prohibits third-party PHI processing must self-host. No managed platform satisfies an air-gapped deployment requirement. This is a binary constraint — if it applies, the decision is made.
Per-connection pricing breaks your unit economics
Managed platforms charge per connection and per message. As you scale, these costs grow linearly while your self-hosted infrastructure cost grows logarithmically. We typically see the crossover point at 5-8 connections — above that, self-hosted saves money even after accounting for engineering time.
See our build vs buy cost breakdown for specific numbers at different scales.
You need access to raw messages
Managed platforms normalize everything into their data model. That normalization strips vendor-specific HL7v2 Z-segments, custom FHIR extensions, and site-specific data elements. If your application needs that data — and clinical decision support apps often do — you need the raw message, which means self-hosted.
Vendor lock-in is a strategic risk
Your application code targets the managed platform's API. If the platform raises prices, changes terms, gets acquired, or shuts down, you are rewriting your integration layer. We have done this migration for clients and it is consistently a 4-8 week project. Self-hosted integration uses standard protocols (MLLP, FHIR REST) that are portable between engines.
The phased approach
Most teams should not pick one model permanently. The phased approach trades short-term cost for long-term control:
Months 0-12: Managed platform for your first EHR connections. Ship your product. Prove the clinical value.
Months 12-24: Deploy self-hosted alongside managed. Route your highest-volume (highest-cost) connections through the self-hosted engine. Keep managed for the long tail.
Months 24+: Migrate remaining connections to self-hosted as the cost-benefit justifies it. Some low-volume connections may stay on managed indefinitely — and that is fine.
The transition from phase 1 to phase 2 is where we see teams call us most. They have product-market fit, their managed integration bill is growing, and they need someone to set up the self-hosted infrastructure without disrupting production.
The decision checklist
| Question | If yes | If no |
|---|---|---|
| Can PHI go through a third-party cloud? | Managed is an option | Must self-host |
| Do you have an engineer who can run Docker? | Self-hosted is viable | Start managed |
| Will you have >8 connections in 18 months? | Model self-hosted cost now | Managed may stay cheaper |
| Is speed to first integration critical? | Start managed | Either works |
| Does your app need raw HL7v2/FHIR data? | Self-hosted preferred | Managed normalization is fine |
We have deployed both models and helped teams transition between them. If you are trying to figure out which approach fits your stage and constraints, we can walk through the specifics.