Open Integration Engine (OIE) specialists design, deploy and maintain the middleware that moves clinical data between healthcare systems. The role covers channel development, standards mapping across HL7 and FHIR, engine migration and production support. Because these interfaces carry protected health information, every deployment must remain HIPAA-compliant, auditable and traceable end to end.
Staffing OIE work is difficult because the project is barely a year old, so the talent pool is drawn almost entirely from engineers who built on Mirth Connect before the March 2025 licence change. Genuine capability requires channel-level engine knowledge alongside fluency in HL7 v2.x, FHIR, X12 and CDA, plus the compliance discipline that clinical data demands. Taction Software is a listed commercial support vendor on Open Integration Engine (OIE) and brings 20+ years of healthcare integration delivery to OIE projects — a direct continuation of our Mirth Connect integration and development and Mirth Connect integration services work.
Our experts are ready to understand your business goals.
Open Integration Engine is an open-source healthcare integration engine licensed under the Mozilla Public License 2.0. It was forked from the Mirth Connect 4.5.2 codebase in March 2025, after NextGen Healthcare moved Mirth Connect to a commercial-only licence at version 4.6, and it is maintained as a vendor-neutral community project. Architecturally it is unchanged from what integration teams already know: messages enter through a source connector, pass through filters and transformers, and leave through one or more destination connectors. Understanding that pipeline is the foundation for everything else on this page.
A channel is the unit of work in OIE. Each one binds a source connector to one or more destinations, with filtering and transformation logic in between. Channels run independently, so a fault in one interface does not halt the rest of the estate.
OIE ships connectors for TCP/MLLP, HTTP and HTTPS, SFTP and file drops, JDBC database reads and writes, web services, and JMS queues. The same connector set covers both inbound and outbound sides, which keeps bidirectional interface design symmetrical and predictable.
Filters decide whether a message proceeds, evaluated against message type, sending facility, patient demographics or any custom rule. Transformers then reshape the payload — HL7 v2.x to FHIR, XML to JSON, proprietary layouts to standards-compliant output — before the destination connector dispatches it.
Complex routing and mapping logic sits in JavaScript, executed at the filter, transformer, connector and channel-deploy stages. This is the same interface engine programming model our team has worked in for years, so existing skills transfer directly.
The Java administrator client remains the primary tool for channel authoring, deployment and message browsing. The community is also developing a browser-based Web Administrator, reducing dependence on desktop Java installs for routine monitoring and day-to-day operational tasks.
OIE is MPL 2.0 with no licence fee, no per-channel charge and no per-interface charge. Governance is public and community-run, and the project applied to join the Eclipse Foundation in June 2026 to formalise vendor-neutral stewardship of the codebase.
Background reading on the underlying goal: our primer on healthcare interoperability.
Adoption is being driven by a licensing event rather than a feature gap. On 19 March 2025 NextGen Healthcare announced that Mirth Connect would become a commercial-only product from version 4.6, leaving 4.5.2 as the final freely available open-source release. That release still runs, but it no longer receives updates, security patches or bug fixes. For organizations with clinical interfaces depending on it, that creates a decision with a compliance dimension: buy the commercial licence, accept an unmaintained engine, or move to a maintained open-source fork. OIE exists to serve the third option.
NextGen’s announcement gave open-source users three paths: remain on their current version indefinitely, move to 4.5.2, or purchase a commercial licence for 4.6 and later. Our NextGen Connect vs Mirth Connect breakdown covers what changed and why.
An integration engine sits at the centre of clinical data flow, which makes an unmaintained version a genuine exposure rather than a deferred upgrade. Newly disclosed vulnerabilities in the engine or its dependencies will not be remediated upstream on 4.5.2.
Commercial licensing introduces a recurring cost that scales with your interface estate and renewal terms. OIE removes the licence line entirely, leaving infrastructure and services as the only variables — which materially changes the economics of a growing interface footprint.
The OIE project describes its 4.5.2 releases as functionally identical to Mirth Connect 4.5.2 with updated branding, and suitable as a drop-in replacement. Existing channels, transformers and deployment patterns generally carry across without redesign or rewriting.
Community governance means no single commercial owner can change the licence, discontinue the product or alter the roadmap unilaterally. For organizations that were caught out once, that structural protection is often the deciding factor rather than a secondary benefit.
Some teams evaluate a managed integration platform instead of self-hosting an engine. Our Mirth Connect vs Redox comparison sets out that trade-off, and most of it applies equally to OIE.
Implementation is where most OIE projects either establish a stable foundation or inherit problems that surface months later under production load. Our work covers environment design, installation, database configuration, security hardening and the deployment topology that fits your infrastructure — whether that is containerised on Kubernetes, provisioned on AWS or Azure, or installed on existing on-premises servers. We treat the engine as production clinical infrastructure from day one, which means high availability, monitoring and backup are designed in rather than added after the first outage.
We map your interface volumes, peak throughput and failover requirements to a concrete topology: node count, clustering approach, load distribution and separation between development, staging and production. The design is documented so your team can operate and extend it independently.
OIE installation includes backing database selection and tuning across PostgreSQL, MySQL, SQL Server or Oracle. This follows the same methodology as our Mirth Connect implementation practice, applied to the open-source fork.
For teams standardising on containers, we deliver Docker images and Kubernetes deployments covering configuration injection, persistent volumes for message storage, readiness probes, and rolling upgrades that avoid dropping in-flight messages.
We deploy on AWS, Azure and Google Cloud using managed database services, private networking, secrets management and infrastructure-as-code. Hybrid designs are common in healthcare, where some source systems remain on-premises and cannot be exposed publicly.
Channel configuration belongs in version control, not in a manual export. We wire OIE into your existing pipelines through our healthcare CI/CD implementation practice so promotion between environments is repeatable and auditable.
Multi-node deployments with shared database backing and tested failover, plus TLS on all connectors, certificate lifecycle management, role-based administrator access and network segmentation aligned to HIPAA technical safeguards.
Migration is the most common reason organizations engage us on OIE, and the shape of the work depends heavily on where you are starting. Moving from Mirth Connect 4.5.2 is close to a lift-and-shift because the codebases are the same generation. Moving from Rhapsody, Cloverleaf, Iguana or a legacy in-house engine is a genuine reimplementation of interface logic. Either way, the sequence is the same: inventory what you have, verify what transfers, run both engines in parallel, and cut over only when message-level output has been proven equivalent.
We catalogue every channel, connector, dependency and scheduled task in the current estate, including the interfaces nobody documented. The output is a migration map that flags what moves cleanly, what needs rework and what should be retired instead of migrated.
Custom plugins, third-party extensions and compiled Java components are the most frequent source of migration surprises. Each is tested individually — see our plugin development work for what replacement scoping involves when something cannot be carried across.
Channels, code templates, global scripts, alerts and server settings are exported from the source engine and imported into OIE. Our channel development tutorial documents the structures involved at a technical level.
Both engines process the same inbound traffic while outbound delivery stays with the incumbent. Comparing message-level output side by side surfaces transformation differences before any downstream system is affected, which is what makes a low-risk cutover possible.
Cutover is scheduled around clinical low-traffic windows with a documented rollback path and defined success criteria, following the discipline set out in our guide to migration validation and cutover.
Rhapsody, Cloverleaf, Iguana and bespoke engines require interface logic to be rebuilt rather than transferred. Our broader healthcare data migration services cover the data-side work that usually runs alongside an engine move.
An integration engine is only as useful as its standards coverage, and healthcare rarely offers the luxury of a single format. A typical estate carries HL7 v2.x from the EHR, FHIR from newer applications, X12 for eligibility and claims, CDA documents for referrals, and DICOM metadata from imaging. OIE handles all of these, but handling a standard and implementing it correctly are different things — most integration defects trace to interpretation of a segment or resource rather than to the engine itself.
ADT, ORM, ORU, SIU, MDM, DFT and MFN flows over TCP/MLLP, including acknowledgement handling and site-specific Z-segment variations. Our HL7 integration services page covers the interface build practice in depth.
Every hospital’s HL7 implementation differs subtly from the published specification. Our reference on HL7 message types and event types is the working document our engineers use when mapping an unfamiliar feed.
FHIR R4 resource mapping, RESTful API consumption and exposure, bundle handling and search parameters. We commonly build HL7 v2.x to FHIR translation layers — see FHIR API development for that capability in detail.
Clinical document generation, parsing and validation for referrals and transitions of care. Template conformance matters here because malformed CCDA documents are frequently rejected silently by receiving systems.
DICOM metadata extraction and routing alongside HL7 order and result flows, connecting PACS and RIS platforms to the wider estate. Modality worklist synchronisation is a common radiology requirement.
Epic, Oracle Health Millennium, Meditech, Allscripts and athenahealth connectivity. Our Cerner and Oracle Health integration guide documents the channel patterns we use in production.
Integration engines are among the highest-value targets in a healthcare estate because every message passing through them contains protected health information. Compliance here is not a document produced at the end of a project — it is a set of design decisions about encryption, access, retention and evidence made while the engine is being built. Our deployments are designed to satisfy HIPAA technical safeguards and to survive an audit, which means the controls have to be demonstrable rather than asserted.
TLS is enforced on every connector carrying PHI, with certificate lifecycle management and cipher policy documented. Database and message store encryption at rest is configured alongside key management appropriate to your infrastructure.
Access control, audit controls, integrity and transmission security are each addressed explicitly at the channel and server level. Our explainer on the HIPAA Security Rule technical safeguards sets out what auditors actually look for.
Message-level logging is configured so any transaction can be traced from source receipt to destination acknowledgement, with retention aligned to your regulatory obligations. This is what makes incident investigation possible after the fact.
Channel design limits PHI exposure: filtering unnecessary fields before transmission, masking sensitive values in error logs and alerts, and ensuring diagnostic output does not leak patient data into monitoring systems or support tickets.
We produce the deployment and control documentation that internal security reviews and customer due diligence ask for, and can run a formal HIPAA risk assessment covering the integration estate.
Engine hardening sits inside a wider posture — network segmentation, identity management, backup and recovery — covered by our healthcare data security practice.
Most of an interface estate’s life is spent in operation, not implementation, and this is where open-source engines are commonly under-resourced. Without a vendor support contract, responsibility for monitoring, patching, upgrades and incident response sits entirely with the organization — which works until the engineer who built the channels moves on. Our managed support covers the operational surface: watching the estate, responding when something breaks, keeping the engine current, and tuning throughput as volumes grow. The objective is that interface failures are detected by monitoring rather than reported by clinical staff.
Channel status, queue depth, error rates, connector health and throughput are monitored continuously, with alert thresholds tuned to your traffic profile. Alerting routes to on-call staff so a stalled interface is caught in minutes.
Failed messages need a defined path back into the pipeline, not a manual rescue each time. Our guide to error handling and reprocessing describes the patterns we implement as standard.
We track OIE releases and security advisories, test upgrades in staging against your channel set, and schedule production upgrades in agreed windows. Staying current is the reason to be on a maintained fork in the first place.
As message volumes grow, queue configuration, thread allocation, database indexing and message storage settings need revisiting. We tune against measured behaviour under real load rather than applying generic recommendations.
Interface changes are requested, tested and deployed through a controlled process with version-controlled configuration and rollback capability. Uncontrolled production edits are among the most common causes of interface incidents.
Where you would rather build the capability in house, you can hire Mirth Connect and OIE engineers to work alongside your team, with knowledge transfer and runbooks as a deliverable.
Our OIE capability is a direct continuation of integration work we were delivering on Mirth Connect long before the fork, which matters because the engines share a codebase generation and the hard-won knowledge transfers intact. Taction Software is listed as a commercial support vendor on openintegrationengine.org, with headquarters in the USA and clients across North America, Europe and Asia. Engagements start with assessment rather than a proposal, because scoping interface work accurately requires seeing the channel inventory and the systems on both ends of it.
Taction is published on the Open Integration Engine project’s commercial support vendor list, covering integration and interface services, migration from other engines, cloud hosting, managed support and custom development.
Our delivery history spans hospital integrations, telehealth platforms, laboratory and imaging connectivity and billing automation, set out in our healthcare integration services overview and across our engagement record.
Every project begins with a scoped assessment of your current engine, channel inventory, standards mix and timeline. You receive a written finding and a realistic estimate before committing to delivery, which avoids proposals built on incomplete information.
Compliance requirements are treated as design inputs. We sign NDAs before project detail is shared, restrict PHI access to named personnel, and build audit-ready workflows as standard rather than as a chargeable addition to scope.
Our team works across HL7 v2.x, FHIR, CDA, X12 and XDS document sharing. Standards depth determines whether an interface handles the specification’s edge cases or fails on the first non-conforming message from a source system.
Delivery model, team structure and accountability are set out on our why Taction page, including how fixed-scope projects, retainers and embedded engineers are structured.
Tell us your current engine, channel count and target timeline. We will come back with a scoped assessment and a realistic estimate.
Open Integration Engine™ is an independent open-source project. Mirth® and Mirth® Connect are registered trademarks of NextGen Healthcare, Inc. BridgeLink is a trademark of Innovar Healthcare. Taction Software is not affiliated with, endorsed by or sponsored by NextGen Healthcare, Inc. or Innovar Healthcare.
Your email address will not be published. Required fields are marked *
Our expert reaches out shortly after receiving your request and analyzing your requirements.
If needed, we sign an NDA to protect your privacy.
We request additional information to better understand and analyze your project.
We schedule a call to discuss your project, goals. and priorities, and provide preliminary feedback.
If you're satisfied, we finalize the agreement and start your project.