[Articles](https://zato.io/articles/index.html)

# Open-Source Cloverleaf Alternative (in Python)

**Infor Cloverleaf is a healthcare interface engine whose interface logic is written in Tcl.

This article describes what Tcl means for the teams that maintain Cloverleaf interfaces, maps Cloverleaf concepts to an open-source platform in Python and presents a sequence for moving interfaces to it.**

By Dariusz Suchojad

![Open-source Cloverleaf alternative in Python](https://zatosource-production.b-cdn.net/static/img/articles/article-04.webp)

11 min. read

Share this article: [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fzato.io%2Farticles%2Fopen-source-cloverleaf-alternative.html) | [FB](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fzato.io%2Farticles%2Fopen-source-cloverleaf-alternative.html) | [Email](mailto:?subject=Open-Source Cloverleaf Alternative article from zato.io&body=https://zato.io/articles/open-source-cloverleaf-alternative.html)

- - -

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](https://www.globenewswire.com/news-release/2010/01/07/149822/0/en/lawson-software-to-acquire-healthvision-solutions-inc.html). Infor acquired Lawson in July 2011, and Koch Industries [completed its acquisition of Infor](https://www.infor.com/news/koch-industries-completes-infor-acquisition) on April 6, 2020. Cloverleaf is now a product of Infor, a subsidiary of Koch Industries.

## Tcl, the language of Cloverleaf interfaces {#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](https://www.tiobe.com/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](https://survey.stackoverflow.co/2026/technology/data/languages-timeseries) 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](https://enovationgroup.com/en/cloverleaf-training-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](https://parkviewcareers.hctsportals.com/jobs/2146943-integration-interface-engineer) requires Level 1 for an integration interface engineer and prefers Level 2, and Infor's own [Cloverleaf consultants](https://sandboxinfor.avature.net/en_US/testpage/JobDetail/Cloverleaf-Sr-Technical-Consultant/14552) 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](https://rhapsody.health/compare-rhapsody-cloverleaf/) 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 {#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](https://clovertech.infor.com/forums/topic/java-and-cloverleaf/), 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.

[![Creating an HL7 MLLP channel for inbound laboratory results in the Zato Dashboard](https://zato.io/docs/gfx/channels/hl7-mllp-create-lab-results.webp)](https://zato.io/docs/dev/healthcare/hl7v2/mllp/index.html)

## Cloverleaf concepts and their Zato counterparts {#cloverleaf-concepts-and-their-zato-counterparts}

| Cloverleaf | Zato |
| --- | --- |
| Site | Zato environment |
| Inbound thread with MLLP | [MLLP channel](https://zato.io/docs/dev/healthcare/hl7v2/mllp/index.html) |
| Outbound thread | Outgoing MLLP connection, used by name in the service |
| Routes in NetConfig | Python, with [match criteria](https://zato.io/docs/dev/healthcare/hl7v2/mllp/config.html#match-criteria) in the channel |
| TPS proc in Tcl | Python service |
| Xlate | Python, with [HL7 v2 fields read and written by name](https://zato.io/docs/dev/healthcare/hl7/v2/field-access/index.html) |
| Lookup tables | [Config tables](https://zato.io/docs/dev/examples/config-tables.html) |
| SMAT files of saved messages | [Audit log](https://zato.io/docs/dev/healthcare/audit-log.html), searchable by patient identifier |
| Resending messages from SMAT | [Resubmission](https://zato.io/docs/admin/audit-log/resubmit.html) from the audit log |
| FHIR services | [FHIR connections](https://zato.io/docs/dev/healthcare/hl7/fhir/index.html) and [HL7 v2 to FHIR conversion](https://zato.io/docs/dev/healthcare/hl7/to-fhir/index.html) |
| Global Monitor | Dashboard |
| Site configuration per environment | [YAML configuration](https://zato.io/docs/admin/enmasse.html) in Git |

## A TPS proc rewritten in Python {#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:

```tcl
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:

```python
# -*- 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](https://zato.io/tutorials/healthcare/hl7v2.html) builds a complete interface of this kind, from an empty environment to a delivered message, in under five minutes.

## Converting Cloverleaf interfaces with AI {#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](https://rhapsody.health/blog/introducing-rhapsody-auto-migrate-enabling-fast-easy-and-low-risk-migration-from-cloverleaf/), 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](https://zato.io/docs/ai/connect-your-copilot.html), 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 {#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](https://zato.io/docs/dev/healthcare/hl7v2/mllp/config.html#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 {#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](https://zato.io/docs/dev/healthcare/audit-log.html) in the Dashboard records every message with its retention configured by you.

[![The audit log of MLLP channels in the Zato Dashboard, with each HL7 v2 message parsed into its segments and fields](https://zatosource-production.b-cdn.net/static/img/healthcare/audit-log.webp)](https://zato.io/docs/dev/healthcare/audit-log.html)

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 {#cloverleaf-and-zato-compared}

|  | Cloverleaf | Zato |
| --- | --- | --- |
| Open source | No | Yes |
| Interface logic in the most popular programming language | No | Yes |
| Interfaces as code instead of graphical designers | No | Yes |
| Developers hired from the largest pool of programmers | No | Yes |
| No license fees | No | Yes |
| Interfaces versioned in your own Git repository | No | Yes |
| HL7 v2, FHIR and REST APIs in one platform | Yes | Yes |
| Enterprise support 24x7x365 | Yes | Yes |

## Frequently asked questions {#frequently-asked-questions}

### Can AI convert TPS procs and Xlate to Python? {#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? {#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? {#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? {#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](https://zato.io/articles/open-source-healthcare-interface-engine.html) article describes them in detail.

### Is Zato open source? {#is-zato-open-source}

Yes. The source code of Zato is [on GitHub](https://github.com/zatosource/zato).

### How do I get started? {#how-do-i-get-started}

Start the [HL7 v2 tutorial](https://zato.io/tutorials/healthcare/hl7v2.html) or [schedule a demo](https://zato.io/services/demo.html).

Dariusz Suchojad is founder of Zato Source.

**Planning a move from Cloverleaf? [Request your customized demo today](https://zato.io/services/demo.html).**
