Clinical systems rarely exchange data with each other directly. A patient administration system emits HL7 v2 admissions over MLLP, a laboratory system sends results in its own variant of the same standard, a regional exchange expects FHIR, and a billing system reads files. An interface engine stands between them. Each system connects to the engine once, and the engine receives every message, reads it, selects the systems that need it, converts it to the form each of them expects, delivers it and acknowledges it to the sender.
Clinical interfaces remain in production for many years, frequently longer than the contract with the engine vendor.
Zato is an open-source healthcare interface engine in Python, and the examples in this article come from it. The healthcare documentation describes each feature in detail.
What an interface engine does
Every interface engine performs the same sequence of steps for each message, whatever names a product gives them. In Zato, each step corresponds to a documented feature:
- Receiving. MLLP channels accept HL7 v2 messages over TCP, in plain text or over TLS, and the same messages can also arrive over REST.
- Parsing. Each message reaches the interface as a typed Python object, so the logic reads
msg.pid.patient_name.family_nameinstead of a field position, and validation reports every problem in a message at once. - Selecting. Match criteria select messages by sending application, facility, message type and trigger event. A default channel receives every message that no other channel matched.
- Converting. HL7 v2 messages become FHIR R4 transaction bundles in one call, with custom Z-segments preserved and conversion warnings reported instead of data being dropped.
- Delivering. One message is delivered to any number of MLLP, FHIR and REST destinations, each in the format that destination expects.
- Acknowledging. The sender receives an AA, AE or AR acknowledgment, and a retransmitted message is recognized by its MSH-10 control ID instead of being processed twice.
- Recording. The audit log stores every message with its acknowledgment, searchable by patient identifier, and a failed delivery is resubmitted from the same screen.
Who controls a clinical interface over its lifetime
An interface built in a proprietary engine exists in that engine's formats - its channel definitions, its scripting language and its runtime. The organization owns the clinical workflow, but the vendor decides how long the engine is sold and patched, which version receives security fixes and on what commercial terms. Events in the interface engine market in recent years show how often these decisions change:
- Mirth Connect. Quality Systems, the parent company of NextGen Healthcare, acquired Mirth Corporation in 2013 and stated that it would continue to serve as the hub for the Mirth Connect open-source community. Thoma Bravo completed the acquisition of NextGen Healthcare in November 2023. In March 2025, NextGen announced that Mirth Connect would be closed source and sold under a commercial license from version 4.6. In September 2026, CISA published three high-severity vulnerabilities affecting every version up to 4.7.1, the last open-source release among them, with the vendor fix available to licensed customers.
- InterSystems Caché and Ensemble. The platforms under many InterSystems integration installations receive no maintenance releases after March 31, 2027. The successor is InterSystems IRIS, and existing installations are migrated to it.
- Rhapsody and Corepoint. Hg acquired Rhapsody from Orion Health in 2018. The company merged with Corepoint Health in 2019, operated as Lyniate from 2020 and returned to the Rhapsody name in 2023.
The hospitals, laboratories and health networks whose interfaces run on these products took none of these decisions. Each of them changed the cost, the support terms or the upgrade path of interfaces that had been in production for years.
With an open-source engine, decisions of this kind do not reach the running interfaces. The source code of Zato is public, and a running installation does not depend on a license contract to keep running. The interfaces are Python code and YAML configuration in the organization's own Git repository, so they remain readable and maintainable whatever happens to any vendor.
Standards and formats in one engine
Healthcare integration covers more than HL7 v2 feeds. In Zato, the following standards and formats are available in the same engine and from the same Python services:
- HL7 v2. Parsing, field access, validation and serialization of every message type, including batch files, and tolerance of non-compliant senders with every repair recorded.
- FHIR. Client connections to FHIR servers with Basic Auth, OAuth, SMART on FHIR Backend Services or mutual TLS, typed R4 resources, searches with pagination and transaction bundles.
- Clinical documents. C-CDA documents such as CCDs, discharge summaries and referral notes are converted to FHIR bundles. Documents arrive by Direct Secure Messaging or in IHE XDM packages.
- EDIFACT. EDIFACT interchanges are parsed into typed objects, including the Dutch healthcare profiles for laboratory results and doctor-to-doctor messages.
- National mandates. IHE XDS.b and XCA document exchange, CDC immunization registries, NHS Spine and Norsk Helsenett are covered in the mandates by land.
Two ways to build an interface
An interface in Zato is configured in the Dashboard without code or written as a Python service. Both kinds use the same channels, connections and audit log, and one environment runs interfaces of both kinds side by side.
Without code. An MLLP channel is created in the Dashboard and its destinations are selected from a list. Every destination receives the message in its own format - MLLP destinations receive it exactly as it arrived, FHIR destinations receive a FHIR bundle converted automatically, and REST destinations receive it as the body of an HTTP request. The channel returns the acknowledgment as soon as it accepts the message, independently of how long delivery to the destinations takes.
In Python. A service is a Python class that the channel invokes with each message it accepts, and the service decides where a message goes and what it becomes. The service below forwards laboratory results to the electronic health record over MLLP and stores admissions in a FHIR server:
# -*- coding: utf-8 -*-
# Zato
from zato.server.service import Service
class ClinicalRouter(Service):
""" Forwards laboratory results to the EHR and admissions to the FHIR server.
"""
name = 'clinical.router'
def handle(self) -> 'None':
# The channel has already parsed the message ..
msg = self.request.input
# .. the message code from MSH-9 selects the destination ..
message_code = msg.msh.message_type.message_code
# .. laboratory results go to the EHR over MLLP ..
if message_code == 'ORU':
result = self.mllp['EHR Results'].send(msg)
self.logger.info('EHR acknowledgment -> %s', result.ack_code)
# .. and admissions are stored in the FHIR server as a transaction bundle.
elif message_code == 'ADT':
bundle = msg.to_fhir()
client = self.fhir['Clinical Data Repository']
response = client.execute('', method='post', data=bundle.to_dict())
self.logger.info('FHIR server response -> %s', response['type'])
When the service completes, the sender receives AA. When the service rejects a message because of its content by raising HL7ApplicationError, the sender receives AE and does not resend the message. Any other exception, for instance a FHIR server that refuses the connection, is answered with AR, and the sender retransmits the message once the cause is resolved.
The HL7 v2 tutorial builds both kinds of interface, from an empty environment to a delivered message, in under five minutes.
The people who maintain the interfaces
Interface engines have traditionally carried their own scripting languages - JavaScript inside a Java runtime in Mirth Connect and its forks, Lua in IguanaX, Tcl in Cloverleaf, ObjectScript in InterSystems products. An analyst who knows HL7 thoroughly still learns the engine's language, and the organization recruits from the comparatively small group of people who already know that particular product.
Mirth Connect and Rhapsody are also Java applications of an earlier generation, whose interfaces are assembled in graphical designers and dialog boxes. A designer makes the first interfaces easy to click together and every later change harder to find, review and repeat across hundreds of channels, because the logic is spread across the panels of individual components instead of being readable in one place.
In Zato, interface logic is written in Python. Healthcare organizations already employ Python developers in their data, analytics and machine learning teams, and Python is the most widely used programming language overall - first in the TIOBE index for October 2026, and used extensively by 58 percent of the developers who answered the 2026 Stack Overflow Developer Survey. Python is also the language of data, machine learning and AI agents, the next generation of healthcare integration. An interface written in Python is read by any Python developer in the organization, reviewed like any other code and written fluently by AI assistants.
Interface analysts who do not program build interfaces in the Dashboard, and developers add Python where an interface requires logic that configuration does not express. Both roles work on the same channels and see the same audit log. AI assistants work with the same interfaces as well - Zato exposes services to AI agents over MCP, under the access controls the organization defines.
Patient data and where the engine runs
Every message an interface engine processes contains protected health information. Zato runs where the organization deploys it - in its own data center, in a private cloud or in its own account with a public cloud provider - so patient data is processed within the organization's perimeter and under its own security policies.
- Retention of patient data. The audit log keeps the record of each exchange separately from the message contents, and each has its own retention period, so events can be kept for a quarter while payloads expire after a week. Each opening of a message body is recorded with the user and the screen.
- Language models. A service that calls a language model sends only the fields the service selects, either to a hosted provider or to a model in the organization's own network, as described in AI in clinical interfaces.
- Review of the software. Security teams review the complete source code, and every Zato image includes a Software Bill of Materials with a signed attestation, before the engine handles any patient data.
Operating an engine that must not stop
Clinical feeds run around the clock, and an interface engine is expected to recover from outages without losing or duplicating messages. In Zato, operations are organized as follows:
- Outages of the engine. MLLP senders keep every message until it is acknowledged and retransmit after an outage. Zato recognizes a retransmission of an already processed message by its MSH-10 control ID and acknowledges it without processing it again, as described in downtime and recovery.
- Outages of a receiving system. Every message sent is stored with its full body, so failed deliveries are resubmitted when the receiving system is available again. When one of several destinations was down, only that destination receives its copy again.
- Diagnosis. Troubleshooting by symptom lists the causes of a silent feed, of a sender receiving AE and of a message that was accepted without reaching its destination.
- Deployment and configuration. Each environment runs from one Docker image, and channels and connections are kept as YAML in Git, so a test environment and a production environment are built from the same definitions.
- High availability. A standby container takes over the traffic when the active container stops responding, as described in the architecture overview.
Enterprise support is available 24x7x365 from the team that builds Zato, including the planning of migrations from other engines and production troubleshooting.
Open-source and proprietary interface engines compared
| Proprietary interface engines | Zato | |
|---|---|---|
| Open source | ||
| No license fees | ||
| Interface logic in the most popular programming language | ||
| Interfaces as code instead of drag-and-drop designers | ||
| Interfaces versioned in your own Git repository | ||
| HL7 v2, FHIR and REST APIs in one platform | ||
| Enterprise support 24x7x365 |
Frequently asked questions
What is a healthcare interface engine?
A healthcare interface engine is software that receives messages from clinical systems, converts them and delivers them to the systems that need them, acknowledging each message to its sender. Each system connects to the engine once instead of connecting to every other system directly.
Are an interface engine and an integration engine the same thing?
Yes. Both terms describe the same kind of software, and vendors use them interchangeably.
Is Zato an open-source interface engine?
Yes. The complete source code is on GitHub, and no feature is reserved for a commercial edition. The license page answers common questions about using it.
Which healthcare standards does Zato support?
HL7 v2 over MLLP and REST, FHIR R4 as a client, conversion of HL7 v2 messages and C-CDA documents to FHIR, Direct Secure Messaging, IHE XDM packages, EDIFACT, and the SOAP-based national exchanges such as IHE XDS.b and XCA, CDC immunization registries and NHS Spine.
How does Zato work with FHIR servers?
Zato connects to FHIR servers as a client, with OAuth, SMART on FHIR Backend Services and mutual TLS, converts HL7 v2 messages and C-CDA documents to FHIR and exposes FHIR data to other systems through REST APIs.
Do interfaces have to be written in Python?
No. Routing a feed to MLLP, FHIR and REST destinations is configured in the Dashboard without code. Python is used where an interface requires its own logic.
Can Zato run alongside an existing interface engine?
Yes. Senders are moved to Zato one interface at a time, while the remaining interfaces stay on the existing engine until each one is verified. The article on the open-source Mirth Connect alternative describes this sequence for Mirth Connect channels.
Where is patient data processed?
On the infrastructure where the organization deploys Zato. No message passes through a vendor's cloud unless the organization configures a connection to one.
How do I get started?
Start the HL7 v2 tutorial or schedule a demo.
- John Adams