OIE Plugins
Open Integration Engine is the Mirth Connect fork I run a production integration stack on. Out of the box it does HL7/FHIR routing and transformation well, but a real deployment needs more than the base engine ships with: clustering across nodes, config backup, secrets from a real vault, SSO account hygiene, and so on. Rather than bolt all of that into one monolithic extension, each concern is its own plugin, its own repo, and its own release cadence — pulled into the Docker image at build time and pinned by version and checksum.
Below is what each one does and where to get it.
The plugins
Cluster — runs several engines against one database as one cluster. A deploy made on any node applies to all of them; channels can be placed on every node or on exactly one; the web console shows every node, what each has deployed, and message counts summed across them.
Backup — backs up engine configuration — chosen part by part — and message history into a single zip, on a schedule or on demand, and restores from one. Ships to this engine, a directory, an SMB share, S3, Azure Blob Storage, SFTP or FTP, optionally encrypted and pruned on a retention policy.
FHIR Connector — a FHIR source connector that presents a RESTful facade in front of a channel, and a FHIR destination connector that performs one FHIR interaction against a remote server. Both speak R4 and R5, selected per connector.
SFTP Connector — two connectors in one extension: an SFTP listener (the engine runs an SFTP server partners push into, or polls a remote server on a schedule) and an SFTP sender that writes each message to a remote server as a file.
Key Store — reads credentials
from Azure Key Vault, AWS Secrets Manager, 1Password Connect and Bitwarden Secrets
Manager, and publishes them as variables channels can use — ${keystore.name} in
any connector field, plus a script API for transformers and deploy scripts. The
point is that a credential stops living in channel XML.
Git Sync — synchronises engine configuration with a git repository and branch, in the shape Databricks Repos has: pull a branch into the engine, and commit/push engine changes back where that's allowed.
Node Monitor — every engine at once: online or offline, uptime, CPU, heap, each disk it writes to, threads, what its channels are doing, and message throughput with an hour of history behind it.
Volume Monitor — watches how many messages each channel receives and reports a fault when a channel falls below an expected volume. Catches the quiet failure: a feed that has silently stopped looks exactly like a healthy one on a dashboard of green channels, because nothing is erroring — there is simply nothing arriving.
Update Check — an "updates available" chip beside the version in the console header, and an Updates page saying what applying each one involves. It reads release feeds for the engine and every installed extension; it never downloads, installs, restarts or upgrades anything itself — that always needs a maintenance window on a stack carrying clinical traffic.
SSO User Guard — makes the web administrator's Edit User dialog read-only for accounts that sign in through the identity provider, and says why: those fields are set from the provider on every sign-in, so local edits would just be overwritten.
Random Generator — a source connector that manufactures HL7 v2 messages on a polling schedule, for when a channel is ready to test and the real upstream system isn't.
Null Connector — a null sender: a destination connector that records every message, acknowledges it, and delivers it nowhere. Useful for channels that only need to count and ack traffic.
How they're distributed
Each plugin is its own GitHub repo with its own releases, built and versioned independently of the engine deployment. The deployment repo's Docker build pulls a pinned version + SHA-256 checksum of each release zip at image build time, so the same plugin set that was tested is what ships — no runtime dependency on GitHub being reachable, and no untracked drift between what's documented and what's running.
