You Are Evaluating a Move from Mirth
Compare staying on your installed version, a supported Mirth upgrade and a move to OIE. Identify the channels, commercial extensions and support requirements that could change the decision.
Eclipse OIE services for healthcare integration teams
Open Integration Engine Migration and Support Services
Move from Mirth Connect to Eclipse Open Integration Engine (OIE), build new healthcare interfaces or support an existing OIE environment. We start with your channels, extensions, database and connected systems, then agree the engineering, acceptance tests and operating responsibilities before implementation.
Updated
Independent healthcare engineering. Scope, access and specialist roles agreed before delivery.
When teams bring us in
When to Bring in an Integration Team.
Hospital and laboratory interface teams, healthcare software companies and integration leads evaluating OIE or already running it.
A Healthcare Product Needs OIE Interfaces
Your application needs patient, scheduling, order or result messages from customer systems. Define the enabled interfaces, mappings, acknowledgements and workflow ownership before building.
OIE Is Installed but Operations Are Unclear
Queue growth, silent feeds, failed destinations and undocumented changes need an owner. Review monitoring, recovery, deployment and support coverage together.
What you can scope
Open Integration Engine Integration Services
Choose the workstream that addresses your current dependency. Each starts with a reviewable output.
Mirth-to-OIE Compatibility Assessment
Inventory source versions, channels, groups, code templates, global scripts, connectors, extensions, custom JARs, database drivers and certificates. Identify what can be tested on the target and what needs replacement or redesign.
DeliverableChannel and dependency inventory, compatibility findings and an estimate with assumptions.
OIE Installation and Environment Setup
Plan test and production environments, database access, service accounts, secrets, network rules, backups and restore. Confirm runtime requirements for the selected release and restrict access to administration interfaces.
DeliverableEnvironment configuration and a repeatable installation and recovery runbook.
Channel and Code-template Development
Build routing, filters, transformations and destination handling for agreed interfaces. Preserve patient and message identifiers and validate the outputs against the receiving system contract.
DeliverableReviewed channel configuration, mappings and synthetic message fixtures.
Migration Testing and Reconciliation
Replay authorized, de-identified test messages into an isolated target. Compare transformed payloads, ACK and NAK behavior, errors and destination acceptance. Keep test destinations isolated from real clinical systems.
DeliverableExpected-versus-observed message report and an exception register.
Cutover and Rollback Planning
Agree endpoint changes, queue handling, switch ownership and stop conditions. Account for messages accepted during the change window, prevent unsafe duplicate delivery and rehearse recovery before release.
DeliverableApproved cutover checklist, rollback triggers and in-flight message reconciliation rules.
Scoped OIE Support and Maintenance
Agree monitoring, alert routing, incident triage, patch review, certificate renewal and channel release procedures. Set support hours, escalation and recovery responsibilities in writing.
DeliverableSupport scope, operating runbooks and an agreed escalation path.
Technical fit
Technical Capabilities
Scope HL7 v2, FHIR, JSON, XML, file, database and HTTP workflows against the selected OIE release, installed connectors and receiving-system specifications. An engine installation does not grant access to an EHR or payer API.
A Fork Is a Starting Point for Compatibility Testing
OIE continues the open-source Mirth codebase. Shared ancestry helps frame the assessment; it does not prove that a particular channel, commercial extension or custom dependency works unchanged.
Separate Delivery, Acknowledgement and Acceptance
Record when a message was received, transformed, sent and accepted downstream. An HTTP success or transport acknowledgement may not establish that a clinical workflow completed.
Runtime, Database and Extension Dependencies
Check the selected release against your Java runtime, database, operating system, drivers and plugins. Test backup restore and administrative access alongside channel behavior.
Access and licensing. The engine repository publishes OIE under MPL 2.0. Review the selected release, plugin licenses and any redistribution obligations for your use. Engineering, hosting and contracted support are separate costs. Customer EHR access and third-party interface permissions remain necessary.
Systems and standards
Systems and Standards in Scope
Supported product features are a starting point. Your system specifications, enabled interfaces and permissions determine the implementation.
EHR and Practice Systems
Patient, encounter and scheduling feeds through interfaces enabled by the customer. Confirm the write destination and the action the source system actually accepts.
Laboratory and Diagnostic Workflows
Orders, results, corrected reports and acknowledgement handling using partner specifications and approved terminology mappings.
FHIR and Product APIs
Map agreed source content to the target API contract. Validate identifiers, resource profiles, permitted operations and the receiving application response.
Files, Databases and Operational Systems
Scope scheduled file exchange, database reads and writes and HTTP connections where the required connector and customer permissions are available.
Migration and controlled change
Mirth Connect to Open Integration Engine Migration
Migration starts with the installed environment and its dependencies. We verify a test copy before recommending a production move, with explicit decisions about messages already queued or delivered.
- 01
Inventory and Select the Target
Document active channels, source version, plugins, custom code and connected systems. Confirm the target release and the operational reasons for changing engines.
Source-to-target inventory and a scoped migration decision. - 02
Build an Isolated Test Environment
Restore or import through the supported route for the selected versions. Replace secrets with test values and use controlled destinations that cannot send messages to real partner systems.
Repeatable test setup and a list of unresolved dependencies. - 03
Replay and Compare Behavior
Test representative normal, invalid and repeated messages, unavailable destinations and recovery after restart. Compare outputs, errors and acknowledgements with the agreed baseline.
Reconciliation evidence and acceptance decisions for each channel. - 04
Rehearse Cutover and Recovery
Agree when the source stops receiving, how queues drain and how endpoints switch. Define which messages may be replayed and how to reconcile writes made after the switch.
Rehearsed change plan with rollback triggers and named owners. - 05
Stabilize and Hand Over
Monitor destination acceptance, queues and errors after the approved cutover. Resolve exceptions and transfer deployment, recovery and incident procedures to the support owners.
Handover record, operating checklist and agreed support responsibilities.
Commercial scope
Choose How We Work Together.
Ask for separate assumptions and fees for assessment, implementation, third-party products and ongoing support.
Compatibility Assessment First
Agree assessment inputs, fee and review date. Receive a dependency inventory, test plan, unresolved questions and a recommendation that may include staying on Mirth.
A Defined Migration or Interface Build
Contract a channel group or rollout milestone with explicit acceptance evidence. Separate engineering effort from access approvals and partner testing windows.
An Ongoing Support Agreement
Define environments, coverage hours, response targets, maintenance responsibilities and exclusions. Review the proposed team and escalation arrangements before service begins.
Choose an assessment, a defined implementation milestone or a support agreement. Fees, delivery dates, staffing, access and response targets are agreed for your environment. A migration is recommended only after the assessment supports it.
Delivery and acceptance
Deliverables Your Team Can Review.
Agree the output, owner and acceptance evidence for each stage. Patient-data handling and production access require your approved process.
- Define
- Interface inventory, mapping specification, dependencies and acceptance criteria.
- Implement and verify
- Reviewed configuration or code, test fixtures and message-level reconciliation evidence.
- Release and transfer
- Deployment and rollback plans, incident runbooks and handover documentation.
Evidence and capability
Engineering Evidence and Platform Staffing.
Nirmitee works across healthcare products, HL7, FHIR, APIs and clinical workflows. Review the public engineering below, then ask for evidence relevant to your specific Open Integration Engine scope.
Public HL7/FHIR Work
Review code, documentation and supported versions. These are adjacent engineering references, not proof of a production Open Integration Engine migration.
Inspect the Mirth integration cookbook Inspect the headless EHR/FHIR repositoryScope-specific Evidence
Confirm the proposed specialist’s experience, availability and responsibilities before engagement. This page does not claim official vendor partnership, certified staff or completed Open Integration Engine projects.
Read the published Mirth hospital integration case study This case study concerns Mirth, not Open Integration Engine. Ask for supporting evidence relevant to your project.Before you commit
Open Integration Engine Service Questions
What is Eclipse Open Integration Engine?
Eclipse Open Integration Engine, often called OIE, is an open-source continuation of Mirth Connect. We provide independent engineering for assessment, implementation and scoped support.
Can we migrate our Mirth Connect channels to OIE?
We assess your source and target versions, channel configuration, plugins and custom dependencies, then test an isolated copy. A successful import alone does not establish equivalent message behavior or a safe production cutover.
Will our Mirth commercial extensions work in OIE?
Do not assume they will. Inventory each extension, check its license and target compatibility, and identify an approved replacement or redesign where needed. Verify the behavior before committing to migration.
Is OIE free to run?
The engine repository uses MPL 2.0. Hosting, engineering, maintenance, plugins and contracted support can still have costs. We separate these items in the scope and confirm license obligations for the chosen components.
Is Nirmitee an official Eclipse or OIE support vendor?
This is an independent engineering offering. It does not establish Eclipse membership, project endorsement, certification or inclusion in a support-vendor directory. Ask for evidence relevant to the proposed team and scope.
Do you provide around-the-clock OIE support?
Coverage hours, response targets and escalation are agreed in the support contract. This page does not promise around-the-clock staffing or a universal service level.
What determines OIE migration cost and duration?
Channel complexity, source and target versions, plugins, custom libraries, environments, testing and cutover requirements determine engineering effort. Customer access, partner test windows and approvals affect elapsed time. We estimate after assessment rather than publish a universal price or deadline.
Can OIE connect to Epic, athenahealth or another EHR?
An engine can participate in a customer-authorized interface, but installation does not grant EHR access. We confirm the customer interface, credentials, supported operations and destination behavior separately.
What should we send for an OIE assessment?
Share your current engine and version, approximate channel count, connected systems, known plugins and your migration or support goal. Keep patient records, message payloads and credentials out of the enquiry form.
A specific next step
Request an Integration Engine Assessment
Share your environment, interface count, standards, migration plans and support requirements. We’ll review the context and propose a delivery model and the specialist roles required.
The first enquiry scopes the next step. Assessment deliverables, fees, staffing and dates are agreed before project work starts.
Prepare with the integration scoping guideThank you. Your enquiry has been received. Our team will review your requirements.
Product References
Vendor documentation informs product terminology. Installed versions, entitlements and support terms need project-specific confirmation.
- Eclipse Open Integration Engine project
- OIE documentation
- OIE source and license
- OIE release notes
- Mirth Connect integration services
- Mirth licensing transition guide
- Mirth alternatives after the licensing change
- Mirth support contract and SLA guide
Open Integration Engine and other product names belong to their respective owners. Nirmitee provides independent engineering services.
Explore healthcare interoperability services