Can we evaluate new engines while the current one keeps running?

Yes. Copy de-identified traffic, or traffic inside a covered environment, to the candidates and compare their output with production. Nothing changes for clinical systems until you choose and plan a cutover.

Do cloud-managed services replace an interface engine?

For some teams. They store and convert messages well, but you still need MLLP connectivity, routing, filtering and partner-specific logic. Many estates keep an engine for routing and use a managed store behind it.

How hard is it to switch engines later?

It depends on how much custom script sits in your channels. Simple mappings move quickly; complex scripts are rewrites. Our interface engine migration service covers the move itself, and the exit test in your proof of concept tells you early.

Does the engine have to be HIPAA compliant?

The engine is part of your HIPAA environment, because it stores and moves ePHI. What matters is how you run it: access control, audit logs, encryption and backups. A managed service also needs a BAA with the provider.

How long does an interface engine evaluation take?

It depends on how many candidates, interfaces and test cases you include. We agree a fixed first release on the scoping call.

Interface engine selection

HL7 interface engine selection: how do you compare engines before you commit?

Interface engines fall into three groups: open-source engines you host, commercially licensed engines, and cloud-managed HL7 v2 and FHIR services. Their feature lists look alike. The differences show up when you replay your own messages, fail a node, reprocess a day of traffic and try to take your configuration with you.

15-Minute Scoping Call All Comparisons

Which criteria separate interface engine types?

Quick answer

An HL7 interface engine selection should be decided by a proof of concept on your own messages, not a feature list: test transforms your team can maintain, failover, reprocessing from the message store, error handling, version control and exit. Agnotic Technologies runs these tests across self-hosted, licensed and cloud-managed engines without ranking products.

Criterion	Self-hosted engine	Cloud-managed service
Transform language	Which language are channels written in, and can your team maintain it?	How are custom mappings written and tested? Azure's $convert-data, for example, uses Liquid templates
Licence and version terms	Read the licence for the exact version you will run, including support and upgrades	Service terms and pricing model; no engine licence
High availability	Clustering or active-passive failover is yours to build and test	The provider runs the service; test what happens when your adapter or network link fails
MLLP connectivity	The engine listens on MLLP inside your network	An adapter or VPN brings MLLP traffic to the service, such as Google's open-source MLLP adapter
Message store and replay	Check retention, search and replay of stored messages to a new destination	Check how long messages are kept and whether you can replay them
Monitoring and alerts	Queue depth, errored messages and stalled channels routed to your on-call	Provider metrics plus your own alerts on message flow
FHIR support	Is FHIR a built-in channel type, a plug-in or custom code?	Often a native FHIR store with conversion from HL7 v2
Configuration as code	Can channels be exported to files, kept in version control and deployed through CI?	Keep infrastructure and mapping templates in your repository
Audit trail	Who changed which channel, and who viewed which message?	The provider's audit logs plus your own
Exit	Export configurations and the message archive; estimate the rewrite of custom scripts	Export stored messages and templates; plan for provider-specific features

What they are

What is Self-hosted engine

A self-hosted engine runs on servers or containers you operate, from an open-source project or under a commercial licence. You build channels in the engine's tools and scripting language, and you own clustering, upgrades, backups and monitoring.

What is Cloud-managed service

A cloud-managed service is a provider-run store and API for HL7 v2 messages, FHIR resources or both, with conversion tools. The provider runs the servers; you bring MLLP traffic to it, configure stores and mappings, and build routing around it.

Key differences

What are the three kinds of engine?

Open-source engines you host give you the code and the operations. Commercially licensed engines add vendor support and a release schedule. Cloud-managed services move storage and scaling to a provider. Licensing terms change over time: NextGen Healthcare now describes Mirth Connect as a licensed integration engine that your organization maintains and operates. Our Mirth Connect assessment checklist covers that change.

Which transform language can your team maintain?

This question decides more selections than any feature. Every engine has its own way of writing transforms: a scripting language in the channel, a graphical mapper, or templates. Ask who will change an interface at two in the morning in a year's time, and pick the language that person already knows or can learn quickly. Then make the proof of concept use it for a real transform.

What do cloud-managed services change?

They change where messages live and who runs the servers. Google Cloud's Healthcare API keeps HL7 v2 messages in an HL7v2 store inside a dataset, and Google documents an open-source MLLP adapter that you run to carry messages over TCP/IP to it. Microsoft's FHIR service offers a $convert-data operation that converts data from several formats into FHIR R4 using Liquid templates. Routing, filtering and partner-specific logic are still yours to build.

Why keep interface configuration in version control?

Because interfaces change often and break quietly. When channels or mappings live as files in a repository, every change has a reviewer, a history and a way back, and the same configuration deploys to test and production. An engine whose configuration can only be edited in a console makes that harder; check how exports work in the proof of concept.

Which audit records does an engine need?

An engine stores messages full of ePHI. The HIPAA Security Rule requires mechanisms that record and examine activity in information systems containing ePHI (45 CFR 164.312(b)). For an engine that means logging who viewed or replayed a message, who changed a channel and when, and keeping those logs where your security team can search them.

When to use each

When to use Self-hosted engine (open-source or licensed)

Most traffic is HL7 v2 over MLLP inside the hospital network.
You need fine control over routing, transforms and retry behavior.
Your team can run a stateful service with on-call and patching.
You already have channels on an engine and want to keep them.

When to use Cloud-managed HL7 v2 and FHIR service

You are building a FHIR-first data platform and need HL7 v2 feeds converted into it.
You want less infrastructure to run and accept provider service limits.
Your systems already run on that cloud, under its BAA.
Routing needs are simple enough to build around the service.

What should an interface engine proof of concept test?

1. Replay a week of your own traffic. Use real ADT, ORM and ORU samples, de-identified or inside a BAA-covered environment, including the odd messages from your oldest systems.

2. Peak-hour throughput. Push your busiest hour at a higher rate and watch queue depth and latency.

3. Node failover. Stop a node mid-stream and confirm nothing is lost or filed twice.

4. Reprocessing. Replay a day of stored messages to a new destination and check the results match.

5. Malformed messages. Send broken segments and wrong encodings, and check the ACK or NAK each sender receives.

6. Duplicates. Resend messages and confirm the downstream system does not file them twice.

7. Alert routing. Break a connection and time how long it takes the right person to be told.

8. A real transform in the engine's language, written by your team, reviewed and deployed through version control.

9. Audit log. Check that message views, replays and channel changes are recorded and searchable.

10. Exit. Export the configurations and the message archive, and estimate what it would take to load them elsewhere.

Which sources does this comparison rely on?

HL7 v2 integration services Mirth vs a custom integration engine Mirth Connect support and migration Interface engine migration and modernization Mirth Connect integration services Infor Cloverleaf integration services

Frequently Asked Questions

No. Most engines tick the same boxes. Choose on what you observe when you run your own messages through the candidates: transform effort, failure handling, replay, monitoring and exit.