perfuse

README

Open-source healthcare integration engine — HL7 v2, FHIR, DICOM, X12 and CDA in one static binary

A modern, Apache-2.0 licensed alternative to Mirth Connect. No JVM. No installer. No paid licence. Your existing Mirth JavaScript runs unchanged.

31 MB of memory at rest, against Mirth's 383 MB — measured on the same machine, both idle. One file to copy instead of a 254 MB install and a Java runtime, and it starts immediately rather than warming up.

Download v0.1.8

      

_{One file, nothing to install. Intel Macs, ARM64 Linux, ARM64 Windows and checksums}

Quick start · Why Perfuse · Mirth migration · Everything it does · Manual · Reference · FAQ

perfuse.health — the manual, the reference and this page, on the web

---

What is Perfuse?

Perfuse is an open-source healthcare integration engine — an interface engine — for moving clinical data between systems that were never designed to talk to each other. A lab sends results in HL7 v2, an imaging department speaks DICOM, a payer sends X12, and the receiving system wants FHIR. Perfuse sits in the middle, parses each of them properly, transforms what needs transforming, and delivers without losing anything.

What it reads and writes: HL7 v2 · FHIR R4, R4B and R5 · DICOM · X12 837, 835, 270/271, 276/277, 834 and 278 · SMART Health Links and Cards · C-CDA and CDA · HL7 v3 · delimited and raw formats.

How it connects: MLLP, TCP, HTTP, SOAP, files, FTP, SFTP, SMB, WebDAV, databases, DICOM, Kafka, message brokers, AMQP 1.0 (Azure Service Bus, RabbitMQ 4), Azure Blob Storage, and AWS — S3, SQS and SNS — twenty source types and twenty-two destination types, in both directions.

What it does beyond moving messages. A durable on-disk queue that keeps ordering and survives a restart. Shadow mode, so a channel can be changed against real traffic while delivering nothing. Feed contracts that tell you when a sender quietly changes something. TEFCA and UDAP for exchanging records with organisations you have no direct connection to. The four CMS-0057 payer APIs, with claims as CARIN Blue Button, prior authorisations as Da Vinci PDex and the yearly metrics page. eCR public health case reporting. SAML, OpenID Connect, LDAP, passkeys, SCIM and mutual TLS for sign-on. Metrics, alerting, tracing, an audit log, and a searchable message store.

And it is one file. Written in Go, licensed under Apache 2.0, running on Linux, macOS and Windows with nothing installed beside it — no Java runtime, no application server, no database to stand up first. The web console is compiled into the binary, and everything the configuration files can express can also be done from the browser. That is a rule this project holds itself to, not an aspiration: a feature reachable only from YAML is treated as a bug.

Everything it does

Fifteen areas, itemised. Nothing here is aspirational: where a capability is partial it says so, and where it depends on something outside this software that is stated too.

Parse, route, transform, generate, acknowledge

A parser that indexes rather than decodes, so reading one field does not rebuild the message

Segments, fields, repetitions, components and subcomponents, with custom Z-segments and non-standard separators

Escape sequences handled properly, including embedded delimiters and hex escapes

MLLP in both directions with TLS, plus TCP, HTTP and file transports

A field dictionary so the interface says "the patient's family name" rather than PID-5.1

Acknowledgement generation with AA / AE / AR, enhanced mode, and control over when the ack is sent — after delivery by default, so a sender is never told "received" before it is true

perfuse generate makes synthetic traffic; perfuse deident turns real messages into a corpus you can share

Usable as a standalone Go library (github.com/biodream-llc/perfuse/hl7) with no dependency on the engine

R4, R4B and R5 — mapper, REST server, validator, destination type

An HL7 v2 to FHIR mapper, not a bolt-on: ADT becomes Patient and Encounter, ORU becomes Observation and DiagnosticReport, SIU an Appointment, MDM a DocumentReference carrying the note, VXU an Immunization, with the date and code conversions done properly

FHIR subscriptions for encounter and appointment notifications (the R5 Backport IG for R4, CMS Interoperability Framework criterion 15), recorded in the same transaction as the change so none is lost across a restart

X12 275 claims attachments in the 006020 form CMS-0053-F adopts, built and read, and X12 278 decisions converted to Da Vinci PAS 2.2.1 ClaimResponses that pass the official HL7 validator

A FHIR REST server you can point a client at — search parameters, bundles, transactions, references

fhir as a destination type, so a v2 feed can deliver to a FHIR API directly

Validation against the specification, and a browser FHIR lab for pasting v2 in and reading the FHIR out

Bulk export, and perfuse fhir for converting, validating and serving from the command line

Verified against a real HAPI FHIR server, which caught an identifier system this code was fabricating

All five services, both directions, with de-identification

C-STORE, C-FIND, C-ECHO, C-MOVE and C-GET — sending and receiving

A DICOM query source: schedule a C-FIND and turn each result into a message

De-identification as a pipeline step — remove the patient, strip private tags, set the AE title

Window and frame selection, and metadata extraction into tags a filter can read

Studies converted into observations that travel onward as HL7 v2 or FHIR

Verified against a real Orthanc PACS: the instance arrives and the patient name, identifier, study date, modality and SOP class all survive. The assertion is Orthanc's own catalogue, not the absence of an error

837, 835, 270/271, 278 — parsed structurally, not as text

837 professional and institutional claims, 835 remittance advice, 270/271 eligibility, 278 prior authorisation

Interchange, functional group, transaction set, loops, segments and qualifiers understood as a structure — not split on delimiters and hoped over

An X12-to-XML representation for transformation, and back again

Da Vinci prior authorisation mapped to and from the X12 278 transaction, which is what CMS-0057 requires

Acknowledgement is not synchronous, and Perfuse says so rather than pretending: X12 uses a 997 or 999 sent separately

C-CDA and CDA, including the ones hidden inside v2 messages

Read, validate and convert C-CDA and CDA, including documents arriving base64-encoded inside an MDM^T02, which is how they usually turn up

The narrative text is compared against the coded entries. A document whose human-readable section disagrees with its structured data is flagged. Nothing else does this

Document templates identified and reported by name

Signing and verification, repair of malformed documents, and PDF rendering

A document destination type, and a browser lab for inspecting one

20 source types, 22 destination types, in both directions

Sources: MLLP · TCP · HTTP · SOAP · file · FTP · SFTP · SMB · WebDAV · database · DICOM · DICOM query (C-FIND) · Kafka · message broker (STOMP) · Amazon SQS · Amazon S3 · AMQP 1.0 (Azure Service Bus, RabbitMQ 4, ActiveMQ) · Azure Blob · JavaScript Reader · serial

Destinations: MLLP · TCP · HTTP · SOAP · SMTP · file · FTP · SFTP · S3 (any storage class, Glacier included) · Amazon SQS · Amazon SNS · AMQP 1.0 · Azure Blob (Hot, Cool, Cold, Archive) · database · DICOM · FHIR · CDA · document · JavaScript · Kafka · message broker (STOMP) · another channel

US Core 9.0.0 for USCDI v6: HL7 v2 converted to FHIR claims US Core only after checking the resource against the profile - Patient, Encounter, labs, diagnoses, allergies, immunizations, notes and more - and the output passes the official HL7 validator with no errors

Signed claims attachments (CMS-0053): C-CDAs in an X12 275 signed to the HL7 Digital Signatures and Delegation of Rights guide - XAdES-X-L with OCSP and RFC 3161 time-stamps - and checked on the way in. Verified by xmlsec1 and OpenSSL

Da Vinci CRD and DTR: a coverage requirements service over CDS Hooks, answering from the payer's rules file whether an order is covered, needs prior authorization, and which questionnaire gathers the documentation - with DTR's $questionnaire-package on the FHIR endpoint. With PAS, the whole CMS-0057 Prior Authorization API. Validated against the official HL7 validator

SMART Health Links and Cards for CMS's Kill the Clipboard: read the QR code a patient shows at check-in, verify the health cards inside, deliver the records to a channel - and share the visit record back as a passcode-protected link this server hosts without holding its key. Tested against the kill-the-clipboard library in both directions

AWS without the AWS SDK: S3, SQS and SNS over signed HTTP, checked against AWS's published signature example and run against LocalStack. An SQS message is deleted only once handled; a FIFO queue keeps each patient's messages in order. An S3 archive can go straight to Glacier by storage class, or be written as date-partitioned JSON for Amazon Athena to query — perfuse athena prints the table

Databases: PostgreSQL, MySQL, SQL Server, Oracle and SQLite, with the dialect checked when the channel is saved rather than at three in the morning

Kafka, keyed so one patient's events stay in order while different patients go in parallel — Kafka orders within a partition and nowhere else, and records sharing a key always share one. Offsets commit after a batch is handled, so a crash redelivers rather than loses

A channel destination so one feed can hand off to another without a network round trip

A fleet view for a site running more than one instance — every channel on every server in one table, with a rollup that counts undetermined separately from unreachable, because a screen of zeros looks like health. Peers are read with a token they issue themselves, and the report between instances carries counts only: no message identifiers, no patient data. Mirth charges for this

SFTP verified against OpenSSH, databases against real PostgreSQL, mutual TLS against OpenSSL — a client and server from the same library agreeing only proves they agree with each other

Eleven declarative steps, or full JavaScript or Lua when you need it

Lua as well as JavaScript: scripts.language: lua runs a channel's filter, transformer and other scripts in a sandboxed Lua 5.1 - no files, no shell, no environment, no code loading, a deadline that cannot be switched off - with the same message tree, maps and logger JavaScript has

Declarative steps that need no code: set, copy, remove, clear, default, case, date, pad, trim, replace, map — each with an optional when condition

Shared mapping tables that outlive the channel that first needed one, with a record of who decided each mapping and why

Code sets and value-set lookups

Attachment extraction: move a large payload out of a message and put it back on the way out

Full JavaScript for the rest — including the Mirth dialect, E4X and all

Three defaults chosen against convenience: an unmapped code is kept rather than blanked, a date that does not match its stated format stops the message, and padding an empty field does nothing rather than inventing an identifier

A durable queue that does not lose messages

A durable on-disk queue per destination, so one slow receiver does not hold up the others

Order is preserved: message 2 is not attempted before message 1 succeeds or is given up on

Retries with exponential backoff, configurable attempts, and dead-lettering that keeps the message. Nothing is deleted to make a queue look healthy

A queue you can inspect, retry, skip and drain from the interface

Survives restart, because it is on disk rather than in memory

Acknowledge after delivery by default, so an upstream sender is not told a message is safe before it is

SAML, OIDC, LDAP, passkeys, SCIM, mutual TLS

SAML 2.0, verified end to end against a real Keycloak 26 and a real Microsoft Entra tenant. Configure it by pasting the provider's metadata — no hunting for a certificate in XML and stripping its line breaks

OpenID Connect, with discovery, and LDAP / Active Directory

A built-in SMART on FHIR authorization server: standalone and EHR launch with PKCE, consent, refresh and ID tokens, Backend Services, granular scopes enforced, token introspection and revocation. Passes Inferno's SMART App Launch STU2.2 suite, 80 of 80

Passkeys (WebAuthn) — fingerprint, face or a security key, and nothing a fake login page can capture

SCIM 2.0, so an identity provider can provision and deprovision accounts directly

Mutual TLS, verified against OpenSSL rather than against our own client

Role-based access control, API tokens for machines, session management, and an audit log of who changed what

Refuses to serve patient data over plain HTTP on a non-loopback address unless explicitly overridden

A rate limiter on authentication, and PHI access auditing with volume, after-hours and bulk-access detection

UDAP, Facilitated FHIR, and the auditing TEFCA requires

This is the part that lets hospitals share records with organisations they have no direct connection to.

UDAP — dynamic client registration, discovery, and signed metadata verification, checked against a real authorisation server and a real trust community

Facilitated FHIR exchange between TEFCA participants, following the SOP

Every exchange is audited, persisted to disk rather than held in memory — TEFCA does not treat auditing as optional and neither does this

Partner discovery with certificate chain verification

The real server refused our client on trust-community membership rather than on the form of the request, which is the distinction that matters: a server rejecting malformed requests would say nothing about whether the signed metadata was right

CMS-0057: the four payer APIs, ready-made

Patient Access, Provider Access, Payer-to-Payer and Prior Authorization — the four FHIR APIs CMS-0057 requires of payers from 1 January 2027, served by the built-in FHIR endpoint, with a screen that says which are ready on this instance and what each still needs

Paid claims to CARIN Blue Button 2.2.0: an 837 and its 835 become professional, inpatient or outpatient ExplanationOfBenefits with their Patient, Coverage, Organizations and Practitioners — no errors from the official HL7 validator on any of the three

PAS decisions to Da Vinci PDex 2.2.0 prior authorizations, tested on the PAS guide's own examples and validated the same way

HRex $member-match for Payer-to-Payer — unique matches only, consent required — and Da Vinci $davinci-data-export on a Group for Provider Access, honouring member opt-outs

The exports apply the rule's exclusions on the way out: no cost-sharing or provider remittances to providers or other payers, and no denied prior authorizations to another payer

The yearly prior authorization metrics page, in the layout of CMS's own template — approvals, denials, extensions, appeals, mean and median turnaround with the unit always written — as a self-contained public page, CSV or JSON

Submits prior authorization requests to payer FHIR APIs, and maps Da Vinci PAS to and from the X12 278, so a payer on either side is reachable

Or be the payer: a Da Vinci PAS 2.2.1 server with Claim/$submit, $inquire and a reviewer's $decide, pended decisions delivered by subscription, and a reviewer queue in the console that reads each pended request with the documents sent for it ($submit-attachment) and approves, denies or certifies fewer units. Inferno PAS Server suite 82 of 84; the two left are must-support elements PAS's own extension contexts forbid there

Da Vinci CRD 2.2.1 over CDS Hooks and DTR 2.2.0 questionnaire packages, so the order, its documentation and the request all have an answer. Drugs are out of scope, as they are in the rule

Inferno's CRD Server 2.2.1 suite passes, and the DTR Payer Server 2.2.0 suite 43 of 45; the two left require an extension DTR's base profile allows zero times

eCR and ELR

Electronic case reporting (eCR): a FHIR destination that sends an HL7 eCR 2.1.2 eICR for each message carrying a reportable-condition trigger code, and nothing for the rest

Triggers from the RCTC you load (or a built-in sample for testing), so a report goes because a code matched rather than because somebody remembered. Validated against the eCR guide with the HL7 validator

The answer comes back: Reportability Responses are received at $process-message and stored where the sent report said to look, and a test agency answers eICRs so the round trip can be tried without one. Proven between two Perfuse servers; the RR validates with 0 errors

Electronic lab reporting (ELR): perfuse elr reshapes a lab's ORU^R01 into an HL7 2.5.1 ELR message carrying only the reportable orders, and says what the lab left out, from the command line or as a channel destination that sends the state only the reportable results. Checked with NIST's HL7 v2 validator, and ONC's ELR certification tool reports all 28 of its example messages valid

Shadow mode, feed contracts, drift detection

Shadow mode: run a candidate version of a channel beside the live one on real traffic, delivering nothing, and read exactly where the two differ field by field. This is how you change a working interface without guessing

Feed contracts: declare what a feed is supposed to contain — which fields, which code sets, which cardinalities — and be told when reality drifts. Most interface outages are a sender quietly changing something

perfuse profile reports what is actually in a feed, and what changed

perfuse compare proves two engines agree over the same traffic, or says precisely where they do not

Channel history read from git, so you can see what changed and when

Dashboard, metrics, alerts, tracing, message store, fleet

A live dashboard, and a flow map with a scrubber — drag it back to a moment and see which strands were dark

Metrics with percentiles, exposed for Prometheus

Team dashboards for each kind of person who watches the interfaces: operations, connections (each partner checked layer by layer, plus VPN tunnel state from AWS, Azure or strongSwan with a printable connection sheet), prior authorization (CMS-0057 timeframes met, late and overdue), imaging, revenue cycle, lab, privacy, exportable to Grafana

Alerts that tell you rather than waiting to be found. Eleven rule kinds: error rate, no traffic, below rhythm (a feed quieter than its own history, which catches a half-broken sender that a threshold misses), channel down, queue depth, queue age, queue stuck, slow delivery, script errors, rows quarantined, and contract violations

Distributed tracing exported over OTLP

A message store with retention, full search, and search inside message content using the same expression language channels filter with — so anything that works in the search box can be pasted into a channel

Find a patient's messages by typing what you know — an MRN, a name, a date of birth, an accession or a claim number — across HL7 v2, FHIR, DICOM and X12 at once, without naming a field in any of them. Matched however it is written, so a message holding SAMPLESON^BRAVO is found by typing Sampleson, Bravo. An index lookup rather than a scan, switchable off, and every search is written to the audit trail with the term

Replay and reprocessing, because the message is stored as received before anything modifies it

Fleet view across multiple instances, and multi-tenancy with isolation rules

Runs as a systemd unit, a launchd service or a Windows service; perfuse init writes the right one

Both directions, verified against Mirth 4.5.2, OIE 4.5.2 and 4.6.0, and BridgeLink 26.9.0

Existing Mirth JavaScript runs unchanged — E4X, msg['PID']['PID.5']['PID.5.1'], for each, XML literals, channelMap, $(), DateUtil, SerializerFactory

perfuse explain reads a Mirth channel export and says by name what converts, what converts with caveats, and what does not convert at all — before you commit to anything

perfuse translate converts the export into Perfuse channels, not a report about them — a channel, a channel group, a code template export or a whole server backup. Code template libraries come across as script files the channels that used them include

Works the same for the Open Integration Engine and BridgeLink, the open-source forks of Mirth. Each engine wrote its own test corpus, and every build translates and runs it

And you can export back. A channel built here can be written as a Mirth channel file, and Mirth, OIE and BridgeLink all accept it. Ten transport pairs verified by importing into each running engine

What cannot convert is refused by name rather than approximated. Filters, transformations, contracts and shadow comparisons have nowhere to live in Mirth's format, and each is listed before the file is offered

A lock-in audit of Java dependencies in your existing channels, so you know what is holding you in place

How small it is

Measured on one machine, both products idle, then Perfuse again after real traffic. Not a throughput benchmark — just what each one costs you to have running.

	Perfuse	Mirth Connect 4.5.2
Memory at rest	31 MB	383 MB
Memory after 5,000 messages	46 MB	—
CPU when idle	0.0%	0.1–0.3%
What you install	one file	a 254 MB application plus a JVM
Runtime to install first	none	OpenJDK 17
Processes	1	JVM + application server

About twelve times less memory at rest, and nothing to install underneath it. Mirth's figure is the JVM's resident size and is configurable; the point is not that the number is fixed but that there is a JVM there at all.

Download size: ~20 MB per platform. Binary: 61 MB, of which 26 MB is the in-browser playground — so the engine, every connector, the parser and the whole web console together are about 35 MB.

Startup is immediate rather than a warm-up: no JVM to boot, no JIT to reach steady state, no application server to deploy into. Restarting a channel is not an event you schedule.

Who it is for

• Integration teams running HL7 v2 interfaces who want the engine's source and no licence renewal
• Sites on Mirth Connect 4.5.2 or earlier, now unable to take upstream fixes
• Anyone building FHIR APIs on top of existing v2 feeds
• Labs, imaging centres, payers and health systems who need X12, DICOM or CDA alongside v2

---

Download

Version 0.1.0 — single binary, nothing to install. Each archive contains the executable, the licence, the notice and the full PDF manual.

Platform	Architecture	Download
Windows	x64 (Intel/AMD)	perfuse-v0.1.8-windows-amd64.zip
Windows	ARM64	perfuse-v0.1.8-windows-arm64.zip
macOS	Apple Silicon (M1–M4)	perfuse-v0.1.8-darwin-arm64.tar.gz
macOS	Intel	perfuse-v0.1.8-darwin-amd64.tar.gz
Linux	x86-64	perfuse-v0.1.8-linux-amd64.tar.gz
Linux	ARM64 / aarch64	perfuse-v0.1.8-linux-arm64.tar.gz

On Windows, unzip and double-click perfuse.exe. It starts the server, keeps its database and channels in %LOCALAPPDATA%\Perfuse, and opens your browser at the sign-in page. The window it opens shows the administrator's password on the first run; keep it open while you use Perfuse, because closing it stops the server. Double-clicking again while it runs just opens the browser. From a command prompt, perfuse with no arguments still prints the usage.

Verify what you downloaded against SHA256SUMS:

shasum -a 256 -c SHA256SUMS --ignore-missing     # macOS / Linux

A CycloneDX software bill of materials ships with every release as perfuse.cdx.json, and any build can produce its own with perfuse sbom -json.

Other ways to install

# Go 1.23 or newer
go install github.com/biodream-llc/perfuse/cmd/perfuse@latest

# Container — the Dockerfile is scratch-based, nothing inside but the binary
docker build -t perfuse . && docker run -p 8080:8080 perfuse

# From source
git clone https://github.com/biodream-llc/perfuse && cd perfuse && make build

The Linux binaries are statically linked and verified to run on Alpine, so they need no glibc and work in scratch and distroless images.

---

What it looks like

Everything below is the interface that ships inside the binary. There is no separate application to deploy.

Dashboard — live channel state and the last 24 hours, with the share of traffic that went wrong readable at the same time as the total.

Messages — every message that arrived, what happened to it, and the bytes as they were sent. The filter box takes the same expression language channels use, so anything that works here can be pasted straight into a channel.

Flow map — every feed and destination on one page, with a scrubber. Drag it back to a moment and see which strands were dark.

Channels — each channel is a file on disk. Anything built in the browser can be edited by hand, and the other way round. To Mirth writes a Mirth channel file that a real Mirth server accepts.

Metrics — volumes, timings and error rates over time, with percentiles, exposed to Prometheus as well.

FHIR lab — paste HL7 v2, see the FHIR it becomes, and validate it. The same conversion the fhir destination type uses.

Quick start

# 1. Start the console. The web interface is inside the binary.
perfuse serve

# 2. Open http://127.0.0.1:8080 and build a channel in the browser.

That is the whole installation. There is no separate web application to deploy and no assets directory to point at.

perfuse init will lay out the directories, write a working example channel and generate a service definition for your operating system — a systemd unit, a launchd plist or a Windows service.

To run a channel from the command line instead:

# Listen for HL7 v2 over MLLP and write each message to a file
cat > labs.yaml <<'YAML'
name: labs
description: Accepts HL7 v2 over MLLP and files each message

source:
  type: mllp
  # Localhost only. MLLP has no authentication or encryption of its own.
  listen: 127.0.0.1:2575

destinations:
  - name: archive
    type: file
    # One file per day per message type, appended. So five ADT messages of two
    # kinds produce two files, not five.
    dir: ./received
YAML

# Check it before running it
perfuse check labs.yaml

# Run it
perfuse run labs.yaml

# In another terminal, send it synthetic traffic
perfuse generate -n 5 -send 127.0.0.1:2575

Everything in the configuration files can also be done from the web interface. That is a rule this project holds itself to, not an aspiration — a feature reachable only from YAML is treated as a bug.

---

Why Perfuse exists

In March 2025, NextGen Healthcare closed Mirth Connect's source. From version 4.6 a paid licence is required. Version 4.5.2 remains available under the Mozilla Public License, which means every site still running it is on a release that will never receive another upstream fix — including security fixes.

That leaves a real problem. Mirth Connect runs a very large share of the HL7 interfaces in production today, those interfaces work, and the people who maintain them did not choose this. Rewriting them is not a weekend's work, and paying to keep receiving patches for software you already deployed is a different proposition from the one you originally accepted.

Perfuse is a way out that does not require a rewrite:

• Your Mirth JavaScript runs unchanged, E4X and all — msg['PID']['PID.5']['PID.5.1'], for each, XML literals, channelMap, $(), DateUtil, SerializerFactory
• perfuse translate converts Mirth channel exports into Perfuse channels, not just a report saying what it found — a whole server backup at once, code template libraries and channel groups included
• The same for the forks. Sites that moved to the Open Integration Engine or BridgeLink rather than pay can come across the same way; both are tested
• perfuse explain reads a Mirth export and says plainly what would block a migration, before you start
• Shadow mode runs the converted channel beside the original on real traffic and shows exactly where the two disagree — while only the original delivers anything
• You can export back to Mirth. A channel built in Perfuse can be written as a Mirth channel file, and a real Mirth server accepts it. Leaving is as supported as arriving.

The last point is deliberate. An engine you cannot leave is the problem, not the solution.

---

Verified against real software, not mocks

Most integration tooling is tested against its own idea of what the other side does. That is how a product ends up with a hundred passing tests and a feature that has never once worked against the real thing.

Perfuse is verified against actual running software. What was checked, against which versions, and what it found is recorded in docs/verification.md:

Verified against	What it proved
Mirth Connect 4.5.2 (real server)	Channels Perfuse exports are accepted and deploy. Found four faults the exporter's own nine passing tests could not see — Mirth stores an invalid channel and returns success
Open Integration Engine 4.5.2 and 4.6.0, BridgeLink 26.9.0 (real servers)	Each wrote its own channels, code template library, group and server backup; every one translates, loads and runs. Found four importer defects, among them a Mapper variable that never reached the script reading it
Keycloak 26	SAML sign-in end to end. Found a signature-canonicalisation defect a thousand self-written tests had missed
Microsoft Entra ID (real tenant)	SAML sign-in with a real Microsoft account, including an interactive browser sign-in. Found five behaviours no reading of the specification predicts
HAPI FHIR	FHIR resources Perfuse produces validate in an independent server
Orthanc	DICOM C-STORE and C-FIND against a real PACS
PostgreSQL, SFTP, ActiveMQ	Database, file transfer and broker destinations against real services
The FHIR R4 specification's own examples	All 2,912 example files the standard's authors published. 13,723 resources validated, none reported wrongly. Found a bundle whose invalid content was being reported as a missing feature, exiting zero under -strict
The HAPI HL7 v2 test corpus	59 of the reference Java implementation's own awkward messages — uuencoded payloads, escaped delimiters, repeating groups — all parsed
SIGKILL, mid-batch	255 messages acknowledged across five hard kills, 255 present downstream, none lost and none duplicated. The numbers for the weaker acknowledgement mode are published too
Inferno, ONC's test kits (run locally)	SMART App Launch STU2.2 80/80 · Da Vinci CRD Server 2.2.1 passes · PAS Server 2.2.1 82/84 · DTR Payer Server 2.2.0 43/45 · US Core 6.1.0 FHIR API 225 → 323 passing. Every failure left is explained in the record
The HL7 validator, on other people's v2	Microsoft FHIR-Converter's 139 samples, 81 French national and NHS Wales samples, the NHS nw-gmsa set and messages posted on chat.fhir.org, converted and validated as whole bundles. What is left are codes the senders sent

Interoperability tests run against containers, not stubs. Where a real product's behaviour contradicted the specification, the real behaviour won and a fixture recording it was committed.

---

---

Migrating from Mirth Connect

# 1. What would stop you, before you commit to anything
perfuse explain server-backup.xml          # Mirth, OIE or BridgeLink; a channel, group or whole backup

# 2. Convert it, code template libraries included
perfuse translate server-backup.xml -o channels/

# 3. Test it against sample messages
perfuse test channels/labs.yaml

# 4. Run it beside Mirth on your real traffic, delivering nothing to anyone
perfuse run channels/labs.yaml

# 5. Prove the two engines agree, on your own messages
perfuse compare -left-name Mirth -right-name Perfuse mirth-out/ perfuse-out/

perfuse explain is the step worth running first. It reads the export and tells you what converts cleanly, what converts with caveats, and what does not convert at all — by name, not as a count. A migration that surprises you in week three is worse than one that refuses on day one.

What does not convert is reported, never silently approximated. Perfuse will refuse a destination type it cannot honour rather than write something close and let you discover the difference in production.

Running it beside Mirth without touching production

Step 4 needs no change to what Mirth delivers. Add one destination to the existing Mirth channel that forwards a copy to Perfuse, and give the Perfuse channel a directory as its only destination:

name: parallel-run
description: Receives a copy of live traffic from Mirth and files the result. Sends nothing onward.

source:
  type: mllp
  listen: 127.0.0.1:2576

destinations:
  # The only destination is a directory, so this channel cannot reach a downstream
  # system even if it is misconfigured. There is nothing else for it to send to.
  - name: what-perfuse-produced
    type: file
    dir: ./perfuse-out

Then perfuse compare pairs the two directories by MSH-10 and reports where they disagree, grouped by cause — so three thousand messages differing for one reason are one finding, not three thousand. Message content is withheld by default, because a report is a thing people paste into tickets. -strict exits non-zero unless the two are identical, which is what makes it usable in a pipeline.

This is the evidence a migration actually turns on, and it costs you nothing but a directory. Nobody has to approve a parallel run that delivers to no one.

Shadow mode is a different tool, for later. It compares a candidate Perfuse channel against a live Perfuse channel, which is how you change a channel safely once you have cut over. It is not how you compare Perfuse against Mirth — perfuse compare is.

Full detail: Migrating from Mirth · Mirth scripts

---

Perfuse vs Mirth Connect

	Perfuse	Mirth Connect 4.6+
Licence	Apache 2.0, open source	Commercial, paid
Source available	Yes	No (closed since 4.6)
Runtime	Single static binary	JVM + application server
Install	Copy one file	Installer, Java, database setup
Memory at rest	31 MB (measured)	383 MB (measured)
Existing Mirth JavaScript	Runs unchanged, E4X included	Native
FHIR	R4/R4B/R5, mapper + REST server built in	Add-on / manual
DICOM	Built in, both directions	Limited
X12	837, 835, 270/271 parsed structurally	Text handling
CDA narrative vs coded comparison	Yes	No
Shadow mode on live traffic	Yes	No
Feed contracts / drift detection	Yes	No
Export back to the other engine	Yes — writes Mirth channel files a real Mirth accepts	N/A
Kafka	Source and destination, keyed for per-patient ordering	No connector
CMS-0057 payer APIs	Patient Access, Provider Access, Payer-to-Payer, Prior Authorization; CARIN BB and PDex output validated by the HL7 validator	Not provided
Configuration from the web UI	Everything	Most things
Multi-server view	Fleet view, included	A paid feature
Published crash-consistency results	Killed mid-batch and counted: 255 acknowledged, 255 delivered	None published

Perfuse is younger and has a smaller connector catalogue. Where a capability is missing it says so rather than approximating it.

---

Measured against an independent gap analysis

Someone designing a Mirth replacement published a competitive capability analysis: 68 candidate features surveyed against 25 engines — Rhapsody, Cloverleaf, Corepoint, InterSystems IRIS for Health, Smile CDR, HAPI FHIR, MuleSoft, Boomi, Kafka, Apache Camel, NiFi, Temporal, Redox and others — each verified rather than assumed, producing 35 confirmed gaps ranked by priority.

It is not about Perfuse. That is what makes it useful: it is an outside view of what a modern interface engine ought to have, written without reference to this one. Perfuse checked against its top ten:

Their recommendation	Perfuse
#1 Silent-interface / SLA / heartbeat alerting — "deadliest failure mode, cheapest win"	Has it — eleven rule kinds, evaluated on a 30s schedule over a 5m window
#2 HA / clustering / failover	Fleet view across instances
#3 Keyed partitioning / per-patient ordering	Stricter than proposed — once anything queues for a destination, everything for it goes behind, and it is not configurable
#4 End-to-end lineage + tracing	Flow map with a scrubber, and OTLP export
#5 Interface test framework in CI	perfuse test
#6 Config-as-code / GitOps	Channels are YAML files in a directory — native, no plugin
#7 FHIR validation + bulk $export	Both built in
#8 AI-assisted mapping	A mapping engine with confidence scores — rules-based, no model, no network call
#9 Aggregator, wire-tap, DLQ	Shadow mode, queue retry, reprocess, replay
#10 OAuth2 credential vault	Partial — UDAP client-credentials for TEFCA

Two of those deserve a caveat rather than a tick. The OAuth2 row is genuinely partial: there is no general credential vault, only the TEFCA path. And #3 is a different trade rather than a better one — the strict rule costs throughput while a queue drains, which was accepted because the faster alternative is silently wrong.

The one clear gap was Kafka, and this release closes it. The report's own advice for the whole streaming category was to ship a Kafka connector rather than build streaming internals, so that an engine becomes the healthcare-aware edge of an event platform instead of competing with one. That is exactly what the connector is: no windowing, no joins, no schema registry, no stream processing. Those stay in Kafka's ecosystem.

---

Documentation

Reference	Every command, connector, transformation step and configuration key
Manual	The full book, with worked examples. Also docs/manual/perfuse-manual.html in a checkout, in every release archive, and served at /manual by a running instance
Manual (PDF)	The same, for printing and for aeroplanes
Verification record	What was tested against which real software, what it found, and what remains unverified
Security	TLS, authentication, audit and what is deliberately refused
HL7 Go API	Using the parser as a library in your own Go programs

The manual is also served by the running instance, so an operator never has to find this page.

---

Using Perfuse as a Go library

The HL7 v2 parser is a standalone package with no dependency on the engine:

import "github.com/biodream-llc/perfuse/hl7"

msg, err := hl7.Parse(raw)
if err != nil {
    return err
}

// Path lookup returns an error for a path that is not valid, rather than an
// empty string that could equally mean "absent" or "you typed it wrong".
family, err := msg.Get("PID-5.1")     // patient's family name
if err != nil {
    return err
}

for _, obx := range msg.Segments("OBX") {
    fmt.Println(obx.Field(3).Component(2).String(), obx.Field(5).String())
}

It indexes rather than decoding, so reading one field does not rebuild the message. API documentation.

---

FAQ

Is Perfuse really free? What is the licence?

Yes. Apache License 2.0 — commercial use, modification, distribution and private use are all permitted, with no fee and no per-channel or per-interface pricing. See LICENSE and NOTICE.

Will my existing Mirth channels work?

Mirth JavaScript transformers and filters run unchanged, E4X included. Channel exports are converted with perfuse translate. Run perfuse explain on your export first — it tells you by name what will and will not convert. Anything that cannot convert is reported rather than approximated.

Can I go back to Mirth if I change my mind?

Yes. A channel built in Perfuse can be exported as a Mirth channel file, and this is verified against a real Mirth server rather than against our own parser. An engine you cannot leave is the problem, not the solution.

Do I need Java, a database or an application server?

No. One static binary. It uses an embedded database by default and PostgreSQL if you point it at one. The web console is compiled into the executable.

Is it HIPAA compliant?

Compliance is a property of a deployment, not of software, so no product can honestly claim it on your behalf. What Perfuse provides: TLS with mutual authentication, an audit log of who changed what, role-based access control, message-store retention limits, de-identification steps, and a refusal to serve patient data over plain HTTP on a public interface unless you explicitly override it. The security chapter is written for the person who has to sign off on it.

Is this production ready?

The engine, queue, transports and web interface are complete and tested, and the parts that talk to other people's software are verified against that software rather than against mocks. Use shadow mode. Run it beside what you have, on real messages, delivering nothing, and read the differences for yourself. That feature exists precisely because you should not take this paragraph's word for it.

What is missing?

A smaller connector catalogue than Mirth's, no clustering yet, and no plugin ecosystem. Filters, transformations, scripts, contracts, shadow comparisons and mapping tables do not survive a round trip out to Mirth and back — each is reported when it cannot be converted. Missing capabilities are refused by name rather than approximated.

How do I get help or report a bug?

Open a GitHub issue. Include the output of perfuse version and, if a message is involved, a de-identified sample. There is also a friction report built into the interface that records where this installation refused you and how often — that is often the fastest way to describe a problem.

---

Contributions are not accepted

This is deliberate, and it is not a judgement about anybody's code.

Perfuse is developed and maintained by BioDream LLC, and it stays that way. Pull requests will not be reviewed or merged. There is no contributor agreement to sign because there is no route for a contribution to arrive.

The reason is the subject matter. This software moves clinical data, and the discipline that makes it worth trusting is that every behaviour is verified against real software rather than against its own assumptions, and that anything which cannot be honoured is refused by name instead of approximated. That standard is easy to state and slow to enforce across contributors, and a half-enforced standard in a healthcare integration engine is worse than no standard at all.

Bug reports are wanted. Open an issue with the output of perfuse version and, if a message is involved, a de-identified sample. A clear report of something that does not work is more valuable here than a patch.

What the licence permits regardless

Apache 2.0 gives you the right to use, modify and redistribute this software, and closing this repository to contributions does not take that away. You may take a copy, change it to suit you, and run or publish the result, commercially or otherwise. What is closed is the path back into this repository — not your ability to do what you like with your own copy. That is the arrangement, and it is the point of the licence.

Building it yourself

make check runs formatting, vet, the race detector, cross-compilation, type checking and the unit suites. make e2e runs the browser tests. docs/releasing.md covers cutting a release and lists what the current one could not verify.

---

Licence

Apache License 2.0. Copyright 2026 BioDream LLC. See NOTICE.

Perfuse is not affiliated with, endorsed by, or derived from Mirth Connect or NextGen Healthcare. HL7 and FHIR are registered trademarks of Health Level Seven International; DICOM is a registered trademark of NEMA. Those marks are used only to describe what this software reads and writes.

Keywords

<sub>Category: healthcare integration engine · interface engine · integration engine · healthcare middleware · clinical data integration · health data integration · healthcare interoperability · medical data integration · healthcare ESB · clinical integration platform · health information exchange · HIE · HIE software · healthcare data pipeline · clinical message router · medical interface engine · EHR integration · EHR integration engine · hospital integration engine · healthcare API gateway

Mirth: Mirth Connect alternative · Mirth Connect replacement · Mirth alternative · Mirth replacement · open source Mirth · Mirth Connect open source · Mirth Connect fork · Mirth migration · migrate from Mirth · Mirth Connect 4.5.2 · NextGen Connect alternative · NextGen Connect replacement · Mirth channel converter · Mirth JavaScript · Mirth E4X · Mirth channel import · Mirth channel export · Mirth Connect licence · Mirth Connect pricing · free Mirth alternative

HL7 v2: HL7 · HL7 v2 · HL7 version 2 · HL7 v2.x · HL7 parser · HL7 v2 parser · Go HL7 library · HL7 interface engine · HL7 router · HL7 transformer · HL7 ADT · HL7 ORU · HL7 ORM · HL7 MDM · HL7 SIU · HL7 DFT · HL7 ACK · HL7 Z-segment · HL7 escape sequences · MLLP · MLLP server · MLLP client · MLLP over TLS · HL7 2.3 · HL7 2.5.1 · HL7 2.7 · HL7 2.8 · HL7 message store · HL7 replay · HL7 de-identification

FHIR: FHIR · FHIR server · FHIR R4 · FHIR R4B · FHIR R5 · FHIR REST API · HL7 to FHIR · HL7 v2 to FHIR · v2 to FHIR converter · FHIR mapper · FHIR validator · FHIR bulk export · FHIR search · FHIR transaction bundle · FHIR facade · SMART on FHIR · US Core · FHIR Patient · FHIR Observation · FHIR DiagnosticReport

DICOM: DICOM · DICOM router · DICOM gateway · C-STORE · C-FIND · C-ECHO · C-MOVE · C-GET · DICOM SCP · DICOM SCU · PACS integration · DICOM de-identification · DICOM anonymisation · radiology integration · imaging integration · DICOM to HL7 · DICOM to FHIR · DICOM query retrieve · modality worklist

X12 and revenue: X12 · X12 837 · X12 835 · X12 270 · X12 271 · X12 278 · X12 parser · EDI healthcare · healthcare EDI · claims integration · remittance advice · eligibility verification · prior authorisation · prior authorization · CMS-0057 · Da Vinci PAS · payer integration · revenue cycle integration · claims 837 · ERA 835

Documents: C-CDA · CDA · CCDA validator · CDA parser · clinical document architecture · CCD · discharge summary · MDM T02 · document integration · CDA to FHIR · clinical document exchange · CDA narrative validation · IHE · XDS

Exchange: TEFCA · TEFCA participant · UDAP · UDAP dynamic client registration · Facilitated FHIR · QHIN · Carequality · Commonwell · national health information exchange · trusted exchange framework · record locator · patient discovery · cross-organisational exchange

Public health: eCR · electronic case reporting · ELR · electronic lab reporting · public health reporting · reportable conditions · syndromic surveillance · immunisation registry · notifiable disease reporting

Security: SAML · SAML 2.0 · SAML single sign-on · OIDC · OpenID Connect · LDAP · Active Directory · passkeys · WebAuthn · FIDO2 · SCIM · SCIM 2.0 · mutual TLS · mTLS · client certificate authentication · role-based access control · RBAC · audit log · PHI audit · HIPAA audit trail · HIPAA integration engine · healthcare single sign-on · Keycloak SAML · Microsoft Entra SAML · Okta SAML · ADFS SAML · API tokens

Operations: durable queue · message queue · guaranteed delivery · dead letter queue · message retry · shadow mode · canary deployment · feed contracts · schema drift detection · interface monitoring · HL7 monitoring · Prometheus metrics · OpenTelemetry · OTLP tracing · distributed tracing · alerting · message search · message replay · multi-tenant · fleet management · flow map · interface dashboard

Transports: SFTP · FTP · SMB · WebDAV · S3 · SMTP · SOAP · STOMP · ActiveMQ · message broker · PostgreSQL · MySQL · SQL Server · Oracle · SQLite · database integration · file drop · serial port

Deployment: single binary · static binary · no JVM · no Java · Go · Golang · Apache 2.0 · open source · self-hosted · on-premise · air-gapped · Docker · container · Kubernetes · systemd · launchd · Windows service · Linux · macOS · Windows · ARM64 · cross-platform · lightweight · low memory footprint · fast startup · free healthcare software · no licence fee</sub>