← All articles

Beyond Redox: When Managed Integration Stops Making Sense

Redox solved a real problem: getting healthcare data flowing without building an integration team. For Series A startups that needed to connect to Epic for a hospital pilot last quarter, Redox was probably the right call. Fast, no infrastructure to manage, pre-built EHR connections.

The teams that call us are usually 12-24 months past that initial integration. Their Redox bill is growing linearly with each new hospital connection. They need access to raw HL7v2 data that Redox's normalization strips. Or their newest contract requires on-premise data processing that a managed platform cannot provide.

If any of that sounds familiar, here is what moving beyond Redox actually looks like.

The triggers we see

The bill crossed a threshold

Redox charges per connection and per message. At 3 connections and 50K messages/month, the bill is manageable ($2,000-4,000/month). At 15 connections and 500K messages/month, it is $10,000-20,000/month. At that scale, a self-hosted engine running on $800/month of cloud infrastructure starts to look compelling — even after you account for the engineering time to manage it.

See our detailed cost comparison for the numbers at different scales.

A contract requires on-premise data handling

Government healthcare, military health, and some enterprise hospital contracts prohibit PHI processing by third parties, even HIPAA-compliant ones. If your newest customer requires on-premise or air-gapped deployment, Redox is structurally unable to meet that requirement. You need a self-hosted engine.

The normalized data model is losing data

Redox normalizes all messages into their standard data model. This works until you need a vendor-specific HL7v2 Z-segment, a site-specific identifier system, or a non-standard FHIR extension that the normalization drops. We have seen this block clinical decision support applications that depend on site-specific data elements that Redox's model does not carry.

You want to own your integration layer

Redox is a dependency. If they change pricing, terms, or API surface, you absorb the impact. If they have an outage, your integrations are down. If they get acquired and the product direction shifts, you are stuck. Some teams hit a maturity point where owning the integration infrastructure feels like a strategic necessity, not just a cost optimization.

The alternatives

For teams that want self-hosted control

MedHook — self-hosted engine with AI-assisted mapping and pre-built EHR adapters. Closest to Redox's "it just works" experience, but on your infrastructure. Free tier to start.

Mirth Connect — open-source, zero licensing cost, massive community. The trade-off is manual configuration for everything. See our Mirth evaluation guide.

For teams that want a different managed option

Health Gorilla — managed clinical data platform focused on data aggregation and retrieval (labs, imaging, claims). Better than Redox if your primary need is pulling patient records from a network, not building bidirectional interfaces.

Particle Health — managed access to patient records through national health data networks (Carequality, CommonWell). Focused on record retrieval, not general-purpose integration.

Neither is a drop-in Redox replacement. They serve different use cases (data aggregation vs. point-to-point integration).

What the migration involves

Moving off Redox is not just swapping infrastructure. Your application code targets Redox's API and data model. Here is what changes:

  1. Data model mapping. Redox normalizes data into their schema. Self-hosted engines work with native HL7v2/FHIR. Your application code needs to consume the native formats instead of Redox's normalized model. This is the bulk of the engineering work.

  2. EHR credential management. Redox manages EHR vendor credentials (OAuth tokens, certificates, VPN connections). On self-hosted, you manage them. For Epic, that means App Orchard registration and per-site OAuth credentials. For HL7v2 feeds, that means MLLP connection management.

  3. Infrastructure setup. Deploy the engine, configure monitoring, set up HA. With Docker and a managed Kubernetes service, this is 1-2 weeks of initial setup.

  4. Connection-by-connection migration. Move one EHR connection at a time. Run Redox and the self-hosted engine in parallel during migration. Validate data parity before cutting over each connection.

Timeline: 4-8 weeks for a team that has done integration work before. Longer if this is your team's first self-hosted integration deployment.

The phased approach

You do not have to migrate everything at once:

  1. Move your highest-volume connections first — this is where the cost savings are largest
  2. Keep Redox for low-volume, long-tail connections where the per-connection cost is below the engineering cost of self-hosting
  3. Route new connections through self-hosted going forward
  4. Migrate remaining Redox connections when contracts renew or when a change is needed anyway

Outgrowing Redox? We have helped teams plan and execute the transition to self-hosted. 30 minutes to walk through your specific volumes and connections.