The Qvera Interface Engine (QIE) is a healthcare integration engine that connects clinical, imaging and administrative systems so they exchange data reliably.
Qvera has built healthcare integration software since 2008. QIE connects electronic health records, imaging systems, laboratory and billing systems and the applications around them, for hospitals and health systems, imaging centers, ambulatory and specialty practices, and the healthcare software vendors who license QIE and embed it in their own products.
Many organizations end up running one tool for clinical messaging and a second for imaging. QIE handles both in one engine, so clinical and imaging interfaces run on the same platform, with one vendor to call and one skill set for the team that runs it. Individual deployments range from a single clinic to more than 10 million messages a day through a single QIE instance.
Three things set QIE apart from other interface engines, and each has its own section below: interfaces are scripted in JavaScript rather than a proprietary language, you choose the database rather than accepting a proprietary datastore, and a built-in AI Companion helps your team build and troubleshoot.
The global system status page: every channel, its state and its queues on one screen.
QIE speaks the standards healthcare systems actually use: HL7 v2 and v3, FHIR, DICOM including native DIMSE, X12, NCPDP, ASTM, CDA and the IHE profiles. Messages move over MLLP, REST, SFTP, file, database, message queue and SMB network share.
Because DICOM support is native rather than added on, the engine that routes an ADT feed can also route studies between modalities, PACS and a VNA, and a legacy DIMSE device can be bridged to a cloud imaging platform without a second product. The complete list of message formats and transports, and what each one supports, has its own page.
An interface in QIE is a channel. A channel has a source that receives or fetches messages, one or more destinations that deliver them, and a chain of nodes between the two that filter, map and transform. You assemble the channel visually, test it against real messages, and watch it run from the same screen. Nothing about its structure is hidden in configuration files.
A change is tested against saved messages before it is promoted, and the global system status page shows every channel, its state and its queue depth on one screen, so the person on call sees a stalled interface before the department does.
A channel, with its source, nodes and destination.
The logic inside a node is JavaScript, the language your team already knows, and the built-in Code Wizard writes the field-level mapping code for you from the message structure. There is no proprietary scripting language to learn and no single vendor’s certification to hire for, which is what makes QIE easier to staff than engines built around their own language.
The knowledge base walks through building a first channel step by step.
The JavaScript editor with the Code Wizard.
The AI Companion is built into QIE, and it knows QIE. Ask it a question about the engine and it answers inside the console. Describe what a mapping should do and it generates the JavaScript against QIE’s own bindings, without your team writing the code by hand. Point it at an erred message and it explains what went wrong and how to fix it, and it reads QIE’s log output and error queues to help troubleshoot connectivity. It works across every message model QIE supports.
Channels can also call a model directly: a dedicated AI web service connection type lets a channel send a message to a model and act on the response the same way it calls any other web service.
The Companion assists your engineers rather than replacing them. A script it drafts goes into your channel only when an engineer accepts it.
QIE runs on the database you already operate: Microsoft SQL Server, MySQL or MariaDB. There is no proprietary datastore, so backups, monitoring and access control follow the practices your database team already has.
Deploy QIE on-premise, in containers, or in your own cloud on AWS, Azure or Google Cloud; the same installer and the same console run in every case. High availability is available on every licensing model. Deployment options, and how an active/passive pair fails over, have their own page.
The Remote Management Hub (RMH) monitors and controls QIE instances running inside separate customer networks from a single console. Each site connects outbound to RMH, so there is no VPN into every customer and no inbound firewall rule to negotiate, and you can open any site’s own administration console from one place. RMH is available with every QIE licensing model.
Security. Qvera’s own controls are attested under SOC 2 Type 2. Inside QIE, connections are encrypted with TLS, users authenticate against local accounts, LDAP or OpenID Connect single sign-on, and role-based access controls who can change what. Field-level RSA encryption and de-identification protect sensitive values in flight and at rest. The attestation, and how to request the report, are available through support.
Pricing. QIE is licensed three ways. Per-channel licensing starts at $9,980 a year for a two-channel block and scales in blocks to 100 channels and more, with volume pricing. Enterprise licensing gives unlimited channels, priced by instance and high-availability node. OEM licensing, for vendors who embed QIE in their own product, bills usage quarterly in arrears plus a partner fee starting at $9,995 a year. High availability is available on all three, and the Remote Management Hub is an add-on to any plan. Prices are in USD; final pricing is confirmed with Qvera sales.
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, for hospitals and health systems, ambulatory and specialty groups, and the healthcare software vendors who build on it.
QuadMed:
Epic interoperability made easy
Revere Health:
Lower costs & improved care
See QIE running your own interfaces.
