Open-Source Cloverleaf Alternative (in Python)


By Dariusz Suchojad
Open-source Cloverleaf alternative in Python

A Cloverleaf installation is divided into sites, and each site runs processes that hold threads - inbound threads that receive messages from clinical systems, outbound threads that deliver them, and the routes between them. A message passes through TPS procs written in Tcl and through Xlate translations, which map one message format onto another, before an outbound thread delivers it.

Cloverleaf has passed through several owners. Healthvision, which began in Dallas in 1989, was acquired by Lawson Software through its parent Quovadx Holdings for 160 million USD in January 2010. Infor acquired Lawson in July 2011, and Koch Industries completed its acquisition of Infor on April 6, 2020. Cloverleaf is now a product of Infor, a subsidiary of Koch Industries.

Tcl, the language of Cloverleaf interfaces

The routes and translations of an interface are configured in the Cloverleaf IDE, and every part of the interface that the configuration does not express is written in Tcl. TPS procs, which run at the user points of control of a thread or a route, are Tcl procedures, and the pre-procs and post-procs of an Xlate are Tcl as well.

Tcl was created in 1988 by John Ousterhout at the University of California, Berkeley. In the TIOBE index for October 2026, Tcl is not among the 50 most popular programming languages - TIOBE lists it alphabetically in the range 51 to 100, without an individual rank. The 2026 Stack Overflow Developer Survey does not include Tcl in its list of languages at all, while the same list includes COBOL, Fortran and Ada.

The developers who write Tcl for Cloverleaf are therefore trained for Cloverleaf itself. Infor certifies them in three levels of courses lasting four and five days each, and Level 2, which leads to the Infor Cloverleaf Certified Engineer title, is the level that teaches Tcl scripts and message manipulation in Tcl. Healthcare employers ask for these certificates in their job postings - Parkview Health requires Level 1 for an integration interface engineer and prefers Level 2, and Infor's own Cloverleaf consultants are required to hold both Level I and Level II.

The consequence for a hospital is that the knowledge of its interfaces is held by a small number of people who know both Tcl and Cloverleaf. Each new interface developer is first trained in a language that is used almost nowhere else, and when an experienced Cloverleaf developer leaves, the hospital recruits from a group of candidates that grows smaller every year.

Other vendors describe the same situation. Rhapsody, a competing interface engine, states on its comparison page that Cloverleaf requires a team with specialized Tcl scripting experience and that such a team is hard to hire for.

From graphical configuration to Python

Besides Tcl, Cloverleaf is a Java application. According to Infor, Java runs the IDE, the host server, the web services adapter and the database protocol, and interfaces are assembled in the graphical NetConfig and Xlate editors of the IDE. Java and graphical designers belong to an earlier generation of integration software. A designer makes the first interfaces easy to click together and every later change harder to find, review and repeat across hundreds of threads, because the logic is spread across dialog boxes, translation files and Tcl procs instead of being readable in one place.

In Zato, an interface is a Python service. Python is the most widely used programming language - first in the TIOBE index for October 2026 with 19.23 percent, and used extensively by 58 percent of the developers who answered the 2026 Stack Overflow Developer Survey. Hospitals already employ Python developers in their data, analytics and machine learning teams, and Python is the language of AI agents, the next generation of healthcare integration.

An interface in Python is read by any Python developer, reviewed like any other code, versioned in Git and written fluently by AI assistants. Interface analysts who do not program configure channels and connections in the Dashboard, and developers write the logic of each interface in any Python IDE.

Cloverleaf concepts and their Zato counterparts

CloverleafZato
SiteZato environment
Inbound thread with MLLPMLLP channel
Outbound threadOutgoing MLLP connection, used by name in the service
Routes in NetConfigPython, with match criteria in the channel
TPS proc in TclPython service
XlatePython, with HL7 v2 fields read and written by name
Lookup tablesConfig tables
SMAT files of saved messagesAudit log, searchable by patient identifier
Resending messages from SMATResubmission from the audit log
FHIR servicesFHIR connections and HL7 v2 to FHIR conversion
Global MonitorDashboard
Site configuration per environmentYAML configuration in Git

A TPS proc rewritten in Python

The TPS proc below processes admissions from a patient administration system. It discards a message without a medical record number, translates the patient class in PV1-2 with a lookup table and passes the message on to the outbound thread of the electronic health record:

proc tps_adt_to_ehr { args } {
    keylget args MODE mode
    set dispList {}

    switch -exact -- $mode {
        start {}

        run {
            keylget args MSGID mh
            set msg [msgget $mh]

            # Split the message into segments and the PID segment into fields
            set segments [split $msg \r]
            set pid_idx [lsearch -regexp $segments {^PID}]
            set pid [split [lindex $segments $pid_idx] |]

            # A message without a medical record number is discarded
            set mrn [lindex [split [lindex $pid 3] ^] 0]
            if {$mrn eq ""} {
                lappend dispList "KILL $mh"
                return $dispList
            }

            # PV1-2, the patient class, is translated with a lookup table
            set pv1_idx [lsearch -regexp $segments {^PV1}]
            set pv1 [split [lindex $segments $pv1_idx] |]
            set pv1 [lreplace $pv1 2 2 [tbllookup patient_class [lindex $pv1 2]]]
            set segments [lreplace $segments $pv1_idx $pv1_idx [join $pv1 |]]

            msgset $mh [join $segments \r]
            lappend dispList "CONTINUE $mh"
        }

        time {}
        shutdown {}
    }

    return $dispList
}

The same interface in Zato is one Python service. The MLLP channel parses the message before the service receives it, so the service reads each field by its HL7 name:

# -*- coding: utf-8 -*-

# Zato
from zato.server.service import Service

class AdmissionFeed(Service):
    """ Forwards admissions from the patient administration system to the EHR.
    """
    name = 'adt.admission-feed'

    def handle(self) -> 'None':

        msg = self.request.input

        # Admissions without a medical record number stop here ..
        if not msg.pid.patient_identifier_list[0].id_number:
            return

        # .. the patient class becomes the code that the EHR uses ..
        classes = self.config.patient_classes
        ehr_class = classes.translate(source='PAS', code=msg.pv1.patient_class)
        msg.set('pv1.patient_class', ehr_class)

        # .. and the message goes to the EHR.
        self.mllp['EHR ADT'].send(msg)

The channel generates the acknowledgment for the sender. The HL7 v2 tutorial builds a complete interface of this kind, from an empty environment to a delivered message, in under five minutes.

Converting Cloverleaf interfaces with AI

TPS procs and Xlate translations are text files, and AI assistants translate them into Python services. The approach is established in the market - Rhapsody offers Auto Migrate, an AI tool that translates Cloverleaf Tcl procs and Xlate into its own dataflows.

With Zato, the result of the conversion is Python, the language that AI assistants write best. An AI assistant reads the NetConfig of a site together with its TPS procs and Xlate files, and writes one Python service per interface. With the Zato documentation connected to it over MCP, the assistant uses the real HL7 v2, MLLP and FHIR APIs of the platform.

Each converted service is then reviewed by your developers and tested with messages saved in SMAT files of the production interface. The same message is processed by the Tcl proc and by the Python service, and the outputs are compared before the Python service receives live traffic. Your team no longer needs Tcl after the conversion, because the Tcl has been read once by the AI assistant and the interfaces from then on are Python.

The migration sequence

A migration from Cloverleaf proceeds one interface at a time, with both engines running side by side for as long as it takes:

  1. Inventory the sites. For each site, record its inbound and outbound threads, its routes, its TPS procs, its Xlate translations and its lookup tables. Interfaces that only deliver messages become channels without code in Zato.
  2. Define the connections. Create the MLLP channels and the outgoing MLLP, FHIR and REST connections, and export them to YAML, so every environment receives the same definitions.
  3. Move the lookup tables. Each Cloverleaf lookup table becomes a config table, which services use to translate the code sets of external systems.
  4. Convert the interfaces with AI. An AI assistant translates the TPS procs and Xlate translations into Python services, and your developers review each service.
  5. Test with saved messages. Messages from SMAT files are sent to the new services, and their outputs are compared with the outputs of the Cloverleaf interfaces.
  6. Switch the senders. Each sending system is pointed to the Zato channel in turn. Deduplication by message control ID protects receivers from duplicates during the switch.
  7. Retire the site. When the last thread of a site carries no more traffic, the site is shut down.

Where Zato runs

Zato runs on your own infrastructure - on physical or virtual servers, in Docker, in Kubernetes and in any cloud. Patient data remains in the systems you choose, and the audit log records every message with its retention configured by you.

Interfaces are Python code and YAML configuration in your own Git repository. Enterprise support is available 24x7x365 from the team that builds Zato.

Cloverleaf and Zato compared

CloverleafZato
Open sourceNoYes
Interface logic in the most popular programming languageNoYes
Interfaces as code instead of graphical designersNoYes
Developers hired from the largest pool of programmersNoYes
No license feesNoYes
Interfaces versioned in your own Git repositoryNoYes
HL7 v2, FHIR and REST APIs in one platformYesYes
Enterprise support 24x7x365YesYes

Frequently asked questions

Can AI convert TPS procs and Xlate to Python?

Yes. An AI assistant translates TPS procs and Xlate translations into Zato services, and with the Zato documentation connected to it over MCP, it uses the real APIs of the platform. Your developers review each service and test it with messages saved from the production interface before it takes over the traffic.

Does my team need to know Tcl to move off Cloverleaf?

No. The AI assistant reads the Tcl, and your team works with the resulting Python services.

Can Zato and Cloverleaf run at the same time?

Yes. During a migration both engines run side by side, and senders are moved to Zato one interface at a time.

Which healthcare standards does Zato support?

HL7 v2 over MLLP, FHIR, conversion of HL7 v2 and C-CDA to FHIR, and REST and SOAP APIs, all in the same platform. The open-source healthcare interface engine article describes them in detail.

Is Zato open source?

Yes. The source code of Zato is on GitHub.

How do I get started?

Start the HL7 v2 tutorial or schedule a demo.

Planning a move from Cloverleaf? Request your customized demo today.

How organizations like yours succeed with Zato

"Zato Source has been a huge asset in helping us do things the correct way. They are really easy to work with, and always come with fresh ideas to help us design what we need."
- Vilberg Eiríksson, Senior Technical Architect at Isavia (KEF)
"Zato Source is the house of problem solvers. They enabled us to overcome major pain points thanks to their ability to really understand and deliver exactly what we need."
- John Adams, Program Manager of Channel Enablement at Keysight
"When you're dealing with a massive company, often it seems they don't really care about you. That's not the case with Zato Source. They are responsive and always available to help."
- Daryl Dusheiko, Chief Solutions Architect at SATO Vicinity
"I would highly recommend Zato Source because it's been such a good experience working with them. They're fast, very reliable, and very proactive. It's a really good, easy relationship."
- Bob Nitekman, Vice President of IT at RRC
Ready to accelerate your digital transformation journey?
Talk to an expert

Schedule a meaningful demo

Book a demo with an expert who will help you build meaningful systems that match your ambitions

"For me, Zato Source is the only technology partner to help with operational improvements."

- John Adams
Program Manager of Channel Enablement at Keysight