If you run DICOM channels on Mirth Connect or its open-source fork OIE (Open Integration Engine), there is a piece of plumbing under your DIMSE listeners and senders that has not had a release in over ten years. It is the dcm4che2 library — the Java implementation that handles every C-STORE, C-ECHO, and storage-commitment exchange your channels make with the imaging world. It works, it is battle-tested, and it has carried a remarkable amount of healthcare imaging traffic. But the world around it has moved on, and the limits of a 2015-era library are starting to show up in real engagements.
We have been working on a path to fix that without forcing anyone to fix anything. The result is an open pull request to the OIE project that adds an optional, modern dcm4che5 backend alongside the existing dcm4che2 backend. This post is the first in a planned series — it covers why we built this, the approach we took to keep upgrades painless, and what the work makes possible next. The PR is still in review, so some of the implementation specifics will likely change before it lands.
The dcm4che Library Underneath OIE
The DICOM Listener and DICOM Sender connectors that ship with Mirth Connect, OIE, BridgeLink, and every commercial Mirth descendant are built on top of dcm4che, a Java toolkit for DICOM. dcm4che is the de facto open-source DICOM library for Java — it is what powers dcm4chee-arc, what universities teach with, and what most third-party DICOM tooling depends on.
The Mirth code base has been pinned to dcm4che version 2 since the connector was originally written. dcm4che2 was the right choice at the time. It is now well behind:
- No releases since 2015. The last public dcm4che2 release (2.0.29, June 2015) predates many of the Java 8+ idioms that have since become standard practice. Bug fixes that have landed in dcm4che5 have not been backported.
- No active security maintenance. TLS guidance, cipher suite recommendations, and transport-layer best practices have all evolved. dcm4che2 reflects 2015’s threat model.
- API conventions from a different era. The dcm4che project itself moved on to a fundamentally different API style with version 3+ — the dcm4che5 line is the actively developed branch and what most modern PACS, archives, and imaging tooling target.
For day-to-day HL7 v2 integration, none of this is visible. Channels keep running. But for organizations that work with DICOM seriously — as Saga does on medical imaging integration engagements — the gap shows up as a series of papercuts: working around limitations that were fixed years ago in the upstream library, missing features that the rest of the imaging ecosystem treats as standard, and an awareness that the security posture of a 2015 library is what it is.
Why a Drop-in Replacement Isn’t Quite Enough
The obvious move — rip out dcm4che2, drop in dcm4che5, ship the next OIE release — is not actually the right move. Mirth’s compatibility story is one of its best features. People build channels and forget about them. Channels that handle ADT messages from a hospital admit-discharge-transfer feed today were often originally configured years ago, sometimes by people who no longer work there. The expectation, correctly, is that an OIE upgrade does not require channel surgery.
The two DICOM libraries differ in places that matter to that expectation:
- Element naming. dcm4che2 uses internal keyword names; dcm4che5 uses the canonical names from DICOM PS3.6. A channel that explicitly references attribute names from JavaScript would see different strings on a hard switch.
- Object types in the JavaScript engine. Scripts that explicitly cast to
DicomObjector useinstanceof DicomObjectagainst the dcm4che2 type would silently break against dcm4che5’s equivalent. (Most scripts that just access fields or use the Object/VR overloads work unchanged because Mozilla Rhino — the JavaScript engine Mirth uses — duck-types method dispatch.) - TLS and connector tuning. Several configuration knobs in the existing connector UI map directly to dcm4che2 internals. A few of those are no-ops or behave differently against the dcm4che5 networking stack.
A forced migration would surface every one of those differences as production incidents the day after the upgrade. The right shape for this work was always going to be opt-in.
The Approach: a Parallel Backend, Not a Replacement
The PR keeps both library versions available inside OIE and lets each server pick which one to use. The default stays where it is — dcm4che2 — so an upgrade is a no-op for installations that don’t deliberately opt in. Operators who want the modern stack flip a single configuration value and restart, and their DICOM channels redeploy onto the new backend.
What makes this more than a feature flag is a small abstraction layer between OIE’s DICOM connector code and whichever version of dcm4che is loaded. The abstraction is intentionally thin — it covers the shapes Mirth’s connector actually touches (DICOM objects, elements, senders, receivers, value-representation handling) and stops there. It exists so the connector itself doesn’t need to know which library version is doing the work, and so future dcm4che API changes can be absorbed in one place instead of rippling through the connector.
There are a few things worth calling out about how we approached this:
Backward compatibility is the explicit success criterion. A user with an existing DIMSE channel who upgrades, doesn’t change any settings, and restarts should see byte-identical behavior to the previous release. We treated any deviation from that as a bug during development.
The default codepath is unchanged. The existing dcm4che2 wrappers, classpath, and entry points all stay where they were. The new backend is additional code, not replacement code.
Migration friction is documented up front. For operators who do choose to switch, the project ships a migration guide that enumerates the few behaviors that differ between the two backends and the script patterns (the explicit casts, mostly) that need a one-line change. We tried very hard to keep this list short.
Reviewer feedback is shaping the final form. OIE’s contributors have raised valid questions about whether this work belongs as a runtime selection inside the existing DICOM connector or as a separate plugin. That conversation is ongoing, and the eventual shape of the change may differ from the draft. We’re committed to whichever packaging the project decides it wants — the abstraction layer and the dcm4che5 backend itself are useful in either form.
What This Means for End Users
The visible effect of this work is small, by design. If you maintain DICOM channels on OIE today:
Your existing channels keep working. Whether or not you opt into the new backend, the channel XML doesn’t change, no fields are renamed, no new required properties are introduced. Channels exported from older OIE versions import without modification.
You get an actively maintained DICOM library when you want it. Operators who need security updates, modern TLS configuration, or features that the dcm4che project has shipped in the last decade have a path to get them without leaving Mirth’s compatibility envelope. dcm4che5 is the same library backing dcm4chee-arc and most of the broader Java DICOM ecosystem — opting in puts your DIMSE traffic on the same code path as the rest of the imaging world’s modern tooling.
Scripts mostly don’t need to change. Channels that read DICOM fields, set attributes, or pass DICOM objects between transformers continue to work. The narrow exception is scripts that do an explicit Java type cast or instanceof check against the dcm4che2 object class — those need a single .unwrap() call, which the migration guide documents in detail.
You can roll back. Because both backends ship in the same release, switching back is the same configuration change in the other direction. There is no deploy or reinstall step. We use this routinely during testing — switch, observe behavior, switch back if something looks off.
For organizations that run DICOM integrations as part of broader healthcare integration engine workloads, the practical effect is that a security-driven upgrade conversation now has an answer that doesn’t require migrating to a different product.
What This Opens Up for Future OIE Releases
The headline of this PR is “modern security updates” but the larger story is about what becomes possible once the connector is no longer locked to a single library version. A few directions we expect to come back to:
Performance work. dcm4che5’s networking stack supports async C-STORE dispatch, more configurable connection pooling, and modern Java I/O patterns. None of those are surfaced through the abstraction layer yet — the goal of this first PR is parity, not optimization. Once the foundation is in place, throughput tuning becomes tractable.
TLS configuration parity with the rest of the platform. The OIE HTTP connectors have well-developed TLS controls (cipher suites, protocol versions, certificate stores). The DICOM connector’s TLS surface has historically been thinner because dcm4che2’s was. Modern dcm4che gives us room to bring the DIMSE TLS story up to the same standard.
DICOMweb and JSON DICOM. The dcm4che project has invested heavily in DICOMweb (QIDO-RS, WADO-RS, STOW-RS) on top of the same library. With a modern backend in place, a DICOMweb listener or sender for OIE becomes a meaningfully smaller piece of work than it would be from scratch.
Better diagnostic tooling. dcm4che5’s logging and observability hooks are richer than dcm4che2’s. We expect to surface more useful runtime information through OIE’s existing logging surface once the abstraction layer is settled.
A path to deprecating dcm4che2 — eventually. Long-term, having two backends in the same code base is not a stable end state. Once the dcm4che5 backend has had broad real-world exercise and the migration story is proven, the project can have a real conversation about what it would take to make dcm4che5 the default and eventually remove dcm4che2. That conversation is best held after the modern backend has been used in anger by people other than us.
These are not commitments — they are directions the work makes available. We expect to come back to them in subsequent posts as concrete features start to land.
Where the Work Stands Today
The PR is open and in active review at OpenIntegrationEngine/engine#299. The technical core — the abstraction layer, the dcm4che5 implementation, the parity tests — is settled, but packaging details (most notably whether this lives inside the existing connector or as a separate plugin) are still being worked out with the OIE community. Specifics like the exact configuration knob may shift before anything ships.
It also hasn’t seen real-world workloads yet. Saga has tested it end-to-end in our own environments, but production-grade PACS testing (Orthanc, dcm4chee-arc, sustained load) is a known gap we’re working to close. This is the first of several planned posts; as the PR matures and concrete dcm4che5-only capabilities land, we’ll cover them here.
Closing Thoughts
DICOM is one of those parts of healthcare integration that, when it works, is invisible. When it doesn’t, it tends to fail in ways that are hard to debug — incompatible transfer syntaxes, mysterious TLS handshake failures, edge cases in C-STORE behavior with a particular vendor’s PACS. A library that hasn’t been touched since 2015 is a quiet liability against that backdrop.
The change we’re proposing isn’t dramatic. It doesn’t add new features the day it lands. It moves the foundation underneath the DICOM connector forward by ten years and gives operators a clean choice about when to take that step. That’s the kind of work that makes the next ten years of features possible.
If your team is running DICOM channels on Mirth Connect or OIE and you’d like to talk through the upgrade path — or if you have specific PACS interoperability or imaging-workload requirements you’d want this to address — we’d welcome the conversation. Saga’s medical imaging integration and healthcare integration engine practices both touch this work, and we have an active interest in real-world testing of the new backend against environments other than our own.
For more context on the OIE ecosystem and how it relates to the wider Mirth Connect landscape, see our posts on OIE vs BridgeLink vs Mirth Connect, Mirth Connect alternatives, and DICOM over TLS with Mirth Connect.