Nexus Health Systems case study: migrating from Iguana to QIE without rebuilding every interface

New case study: Nexus Health Systems moves from Iguana to QIE without rebuilding every interface

Qvera has published a new case study on Nexus Health Systems, a Houston-based health system with a network of hospitals and residential treatment centers across Texas. Nexus moved its production interfaces from iNTERFACEWARE Iguana to the Qvera Interface Engine (QIE) without rewriting them and without interrupting message flow, using the AI Companion built into QIE to port its existing Lua scripts to JavaScript.

What did Nexus need from a new interface engine?

Nexus needed flexibility in how and where its engine runs, real depth in healthcare integration, and the ability to move quickly. An integration project was already on the schedule, and a migration measured in quarters would have stalled it. Four things shaped the decision:

  • Deployment flexibility: QIE runs on-premise, in containers, or in your own cloud on AWS, Azure or Google Cloud, with high availability available on every license.
  • Security posture: Qvera is SOC 2 Type 2 attested.
  • Healthcare integration experience: Qvera has built healthcare integration software since 2008.
  • The AI Companion: built into QIE, and the part that mattered most during the migration itself.

How did the interfaces move without being rebuilt?

  • The channel structure maps across. Iguana’s From, Translator and To components line up with QIE’s receiver, mapping and destination nodes, so channel scaffolding and connection settings are converted rather than re-specified by hand.
  • The existing Lua is the specification. Those scripts already encode what each interface does, so the requirements-gathering stage of a normal interface build was largely unnecessary.
  • The AI Companion ports Lua to JavaScript. It writes scripts against QIE’s own bindings and explains existing code, and it did most of the work of translating Nexus’s transformation logic.
  • A Qvera engineer validated each interface before it went live.

“Our biggest concern going in was how much of our existing Iguana work would have to be redone. It was a much smaller lift than we thought. Our existing Lua code already defined what each interface needed to do, and the AI Companion handled the bulk of translating that into QIE scripts. Every interface is now running in production, with effectively no downtime.”

Josh Atchley, Senior Manager, Platform & Infrastructure, Nexus Health Systems

What happened to message flow during the cutover?

Nothing stopped. Nexus moved its interfaces incrementally rather than in a single switchover, and the systems it feeds saw no interruption in service. The integration project that was already on the schedule was never held up.

Running Iguana today?

Your Lua scripts, transformations and routing logic are the specification for the QIE build, so moving does not mean discarding the work already invested in your integrations. A migration assessment reviews your current Iguana channels, maps them to QIE, and gives you a clear picture of the effort and timeline. There is no obligation and no charge. If you are still comparing engines, see how QIE compares with Iguana 6 and IguanaX.

Running Mirth Connect?

QIE converts a Mirth Connect configuration directly into QIE channels, so Mirth teams also start from their existing channels rather than rebuilding them. See how QIE converts Mirth channels, and how it compares with Mirth 4.5.2, Mirth 4.6+ and the community forks.

Read the full case study

Download the PDF • Schedule a demo • Request a free trial