The Qvera Interface Engine (QIE) is a strong fit for software vendors and healthcare organizations that want to own their integrations: build and change interfaces themselves, run the engine in their own cloud, in containers or inside a hospital’s network, and pay by channel rather than by message. Qvera engineers are available to assist with each connection, high availability is included on every licensing model, and HL7, FHIR and DICOM run in the same engine. If you want one vendor to build, host and run every EHR connection for you and bill by transaction volume, that is what Redox sells, and QIE is not that. QIE is in production today at more than 600 sites, running more than 25,000 interfaces and processing more than 50 million messages a day.
Redox and QIE solve the same problem, moving data between your software and the systems it needs to reach, in two different ways.
Three questions settle which you are buying. Do you want to keep an existing Redox service for the connections it already carries and use an engine for new ones, or replace it? How many connections would need building? And who on your team will own the interfaces once they run?
Six things teams ask about when they weigh Redox against running an engine:
Yes, one connection at a time. A Redox integration is a connection Redox built between your software and a hospital’s EHR, delivered through Redox’s data models or its FHIR API. There is no file to convert. Moving it means building that connection again as a QIE channel on the hospital’s own HL7 or FHIR interface, the same interface the hospital exposes to the other systems it works with.
Redox cells come from Redox’s own website, documentation, pricing page and legal pages, reviewed on 15 October 2026. Redox’s documentation is public, so “not published” means the item does not appear in it, not that it is proven absent.
| What you are buying | QIE | Redox Engine |
|---|---|---|
| What it is | Software you install and run: on your own servers, in containers, or in your own cloud account | A hosted service: “100% cloud hosting” on Amazon Web Services and Google Cloud; nothing installed on your premises; you connect to it over the internet |
| Who builds each connection to an EHR or partner | Your team, in the channel editor, with Qvera engineers available to assist | Redox: “We build a system adapter for each system Redox integrates with”; your team codes to Redox’s API and provides a public HTTPS endpoint |
| Who runs it day to day | Your team, or Qvera under an Integration Services engagement | Redox: “we handle all ongoing monitoring, updates, and support” |
| Building interfaces | QIE | Redox Engine |
| How an interface is built | Channel editor: receiver, mapping, condition and destination nodes | Configuration in a web dashboard: config modifiers, filters, value sets and translation sets; content-based routing in the Advanced tier |
| Scripting language | JavaScript, which can call Java libraries | not published; logic beyond configuration lives in your own code or in Redox’s managed services |
| Testing with sample messages | ✓ step-by-step testing with sample messages | ✓ developer environment and test tools in every tier; staging and production environments |
| AI assistant in the product | ✓ AI Companion, with every license; an MCP server will be available in the 26.4 release | ✓ AI assistants and an MCP server (June 2026), in the Core and Advanced tiers |
| Configuration history | ✓ every change, compare and restore | not published |
| Standards and connections | QIE | Redox Engine |
| HL7 v2 | ✓ over MLLP, HTTPS, files and more | ✓ “HL7v2 over HTTPS”, or MLLP inside a VPN tunnel you build to Redox’s cloud |
| CDA and HL7 v3 | ✓ | C-CDA ✓; HL7 v3 messaging not published |
| FHIR | ✓ as a client and producer, JSON and XML, OAuth 2.0 and SMART on FHIR scopes; not a FHIR server | ✓ the Redox FHIR API, FHIR subscriptions, SMART on FHIR, CDS Hooks |
| X12 and NCPDP | ✓ | X12 ✓; NCPDP not in the published methods list |
| DICOM networking (store, query, retrieve, verification, worklist) | ✓ in the engine | DICOM listed as a data format and DICOMweb as a method; DICOM network roles not published |
| Direct connections to databases, message queues and network shares | ✓ | not published; the published methods are HTTPS, SFTP, cloud storage, webhooks and polling |
| Running it | QIE | Redox Engine |
| Where it runs | Windows, Linux or macOS; vendor-published container images; Kubernetes, including Azure Kubernetes Service; AWS Elastic Container Service; your own AWS, Azure or Google Cloud account; on-premise | Redox’s cloud only, on Amazon Web Services and Google Cloud; no on-premises, self-hosted or container edition published |
| Database | Microsoft SQL Server, MySQL or MariaDB, under your control | none to run; Redox holds the data |
| High availability | ✓ two or more nodes share one database, automatic failover; included on every licensing model | Service Level Agreement: “at least 99.95% System Availability during each calendar month” |
| Many sites from one console | ✓ Remote Management Hub (RMH): sites connect outward, no inbound firewall rule or VPN per site | one dashboard for your Redox organization |
| Where your message data lives | In your database, under your retention policy | In Redox’s cloud; full payloads containing PHI are kept 60 days, as published |
| Security and support | QIE | Redox Engine |
| Security attestations | SOC 2 Type 2 | SOC 2 Type 2 “consistently since July 2017”; HITRUST r2, as stated on its platform security page; HIPAA and GDPR statements |
| Support | 24/7 for system-down emergencies; phone support (8am to 5pm Mountain), email, customer portal and knowledge base | Business hours 7 AM to 7 PM Central; response targets of 15, 60 and 120 minutes by severity for live connections; after hours for critical production issues only |
| Documentation | public, at qvera.com/docs | public, at docs.redoxengine.com |
| Licensing | QIE | Redox Engine |
| Model and published prices | Channel-based, Enterprise or OEM; production, test and developer licenses included; Channel-based licensing starts at $9,980 per year for 2 channels; see pricing below | A platform tier plus an annual consumption fee by transaction volume. As published on Redox’s pricing page on 15 October 2026: Sandbox “Starting at $15k/year”, for companies under 500 employees and “Not applicable for Providers, Payers, or Enterprise organizations”; Core “Starting at $35k/year”; Advanced, “Contact our team” |
Yes, in one engine. Anything QIE does for HL7 v2 it also does for HL7 v3, FHIR, DICOM including native DIMSE and DICOMweb, X12, ASTM, CDA and IHE profiles, over MLLP, REST, SFTP, file, database, message queue and network share. The Qvera DICOM Router is that same engine configured for imaging.
QIE works with FHIR as a client and a producer: it calls FHIR servers, including those behind OAuth 2.0 and SMART on FHIR, and produces FHIR from HL7 v2, CSV and database data. It is not a FHIR server. Redox offers its customers a FHIR API that Redox hosts; if your product needs a FHIR endpoint that someone else hosts and maintains, weigh that difference.
It runs on Windows or Linux, in Docker or Kubernetes from images Qvera maintains, or on AWS ECS: on-premise, in containers, or in your own AWS, Azure or Google Cloud account, against Microsoft SQL Server, MySQL or MariaDB. Running engines at more than one site, or inside networks you do not control, is what the Remote Management Hub (RMH) is for.
The Qvera Interface Engine · The Qvera DICOM Router · Remote Management Hub
Whichever options are on your shortlist, hosted services or engines, ask every vendor, Qvera included, to show one of your own connections end to end: who builds it, how long it takes, how a change is made once it is live, how it is tested, and what the complete cost is at your message volume and customer count, with support, high availability and test environments included.
See how QIE compares with Iguana 6 and IguanaX, and how Iguana teams move their Lua interfaces.
See how QIE compares with both, what its license includes, and how interfaces move.
Qvera offers Channel-based, Enterprise, and OEM licensing models. Channel-based licensing starts at $9,980 per year for 2 channels and does not limit message volume. OEM licensing is for partners embedding or distributing QIE in their own product. View Qvera Licensing and Pricing.
QIE is in production at more than 600 sites, running more than 25,000 interfaces and processing more than 50 million messages a day. Qvera has built healthcare interface engine software since 2008 and is SOC 2 Type 2 attested.
How this comparison is sourced: Qvera publishes this page and sells QIE. What this page says about QIE comes from Qvera’s own product documentation and production deployments; about Redox Engine, from Redox’s own website, documentation, pricing page and legal pages. All Redox information was last reviewed on 15 October 2026. Vendors change their products, so check their current documentation before relying on any single claim. Found something out of date? Tell us and we will correct it.
