Eclipse Open Integration Engine

Thursday, June 4, 2026 - 08:06 by Paul Richardson
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Community Review
Background

For two decades, Mirth® Connect by NextGen® Healthcare was widely adopted across the world as an open-source healthcare integration engine. Following a shift by its corporate owner (NextGen Healthcare / NXGN Management, LLC) toward a closed-source/proprietary model, the healthcare IT community recognized the critical need for a continued open-source alternative. This led to the creation of a vendor-independent open-source fork by a group of long-term contributors: the community-driven Open Integration Engine (OIE).

Scope

Eclipse Open Integration Engine project provides a robust, flexible, and extensible integration engine tailored for healthcare data exchange. It facilitates the transformation, routing, and filtering of messages across disparate systems using standards such as HL7v2, FHIR, and DICOM. The project maintains the core engine, administration utility and documentation.

  1. A cross-platform, Java-based integration engine capable of receiving, transforming, filtering, routing, and delivering clinical and administrative messages between disparate healthcare systems.
  2. Native support for healthcare interoperability standards in common production use, including HL7 v2.x, FHIR, DICOM, and CDA, alongside general-purpose data formats such as JSON, XML, and delimited text.
  3. A library of protocol connectors covering the transports typically required in healthcare environments, including HTTP/S, TCP/MLLP, FTP/SFTP, SMTP, file system, JMS, and direct JDBC database connectivity.
  4. A management and administration application providing channel authoring, deployment, operational monitoring, and message auditing.
  5. A scripting and transformation framework allowing implementers to express channel logic in JavaScript, with extension points for additional languages and custom code.
  6. A plugin and extension API allowing third parties to contribute connectors, transformers, code templates, and management console extensions without modifying the core engine.
  7. Reference documentation, administrator guides, developer guides, migration guidance for users coming from upstream forks, and example channels.
  8. Build, packaging, and release tooling sufficient to produce reproducible binary distributions for supported platforms.
Description

Every hospital, clinic, and lab runs on a patchwork of software systems that were never designed to talk to each other. A patient's record might live in one application, their lab results in another, their imaging in a third, and their billing in a fourth - each speaking a different digital language, often built decades apart. Getting these systems to share information reliably is one of the most persistent and expensive problems in healthcare, and it is the problem the Eclipse Open Integration Engine exists to solve.

Eclipse Open Integration Engine sits between healthcare systems and translates between them. When one system needs to send information to another, the engine receives the message, converts it into a format the receiving system understands, applies any rules the organization has defined, and delivers it. It does this thousands or millions of times a day in production environments around the world, quietly handling the flow of clinical and administrative data that keeps a healthcare organization running. Healthcare IT teams use it to connect electronic health records to laboratory systems, to route imaging orders, to feed data warehouses, to exchange information with public health registries, and to bridge older systems with modern, standards-based interfaces.

The project provides three things: the engine itself, an administrator application for designing and monitoring message flows, and the documentation needed to operate both. Implementers organize their work into channels, each representing a single integration between systems. A channel defines where messages come from, what should happen to them along the way (filtering, transformation, enrichment, routing), and where they should go. Channel logic is expressed in a combination of configuration and JavaScript, which gives integration teams enough flexibility to handle the unusual real-world cases that healthcare data is famous for, without forcing them to build and deploy custom applications.

Under the hood, Eclipse Open Integration Engine is a cross-platform integration engine (written in Java) that acts as an interpreter for healthcare systems, translating message standards into formats that target systems can process. The engine allows health IT teams to manage message pathways (channels) through filtering, transformation, extraction, and routing stages. It supports bidirectional conversion between standards like HL7, JSON, and XML. The project features a modular architecture with custom JavaScript-based scripting and connectors for protocols like HTTP/S, FTP, and direct database connectivity. It also includes a management administrator interface for channel development and operational monitoring.

Why Here?

The Eclipse Foundation's proven, vendor-neutral governance model is exactly what is required to underpin public and corporate trust in OIE. Operating under the Eclipse Foundation eliminates concerns over unilateral corporate control of the roadmap by placing direct competitors on a level playing field governed by open, transparent, and meritocratic rules. Furthermore, the Eclipse Foundation's Intellectual Property team and trademark management provide the legal framework needed to confidently manage the transition away from the original Mirth Connect branding.

Future Work

The immediate focus is continuing the ‘business-as-usual’ processes of identifying and rectifying any critical vulnerabilities and clinical safety issues, and then shaping the next release based on Github issues raised by the user community. Beyond that, future work will focus on expanding the plugin ecosystem, improving documentation, enhancing the UX/UI of the administrator interface, and expanding native support for modern healthcare standards such as FHIR.

Project Scheduling

The initial contribution is available at present. There have been 2 public releases to date, with another soon to be released. Moving forward, the project plans to release 2 feature versions per year.

Committers
Nico Piel (This committer does not have an Eclipse Account)
Mitch Gaffigan (This committer does not have an Eclipse Account)
Kiran Ayyagari (This committer does not have an Eclipse Account)
Tony Germano (This committer does not have an Eclipse Account)
Kaur Palang (This committer does not have an Eclipse Account)
Interested Parties
  • The Open Integration Engine core maintainers and community contributors
  • Healthcare system vendors
  • Clinical research system vendors
  • Healthcare providers
  • Public health establishments
  • Pathology laboratories
  • Healthcare integration consultancies
  • Individual healthcare integration developers
  • Existing Mirth Connect customers and users
Initial Contribution

The initial contribution will be the existing Open Integration Engine (OIE) source code repositories. The project comes with a strong base of contributors (20), 7 of whom were new to the latest RC release. In addition, there is a strong and growing number of commercial partners

Source Repository Type