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.

[](LICENSE) [](https://go.dev) [!Release](https://img.shields.io/badge/release-v0.1.3-success.svg) [!Platforms](https://img.shields.io/badge/platforms-Linux%20%7C%20macOS%20%7C%20Windows-lightgrey.svg) [!Tests](https://img.shields.io/badge/tests-verified%20against%20real%20Mirth%2C%20Keycloak%20%26%20Entra-brightgreen.svg)

Download v0.1.3

       _{One file, nothing to install. [Intel Macs, ARM64 Linux, ARM64 Windows and checksums](#download)}

Quick start · Why Perfuse · Mirth migration · Everything it does · [Manual](/manual/) · [Reference](/reference/) · FAQ

[perfuse.health](https://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 and 278 · C-CDA and CDA · HL7 v3 · delimited and raw formats.

How it connects: MLLP, TCP, HTTP, SOAP, files, FTP, SFTP, SMB, WebDAV, databases, DICOM, message brokers and S3 — fourteen source types and seventeen 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. Prior authorisation to payer FHIR APIs for CMS-0057. eCR and ELR public health 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, with the date and code conversions done properly
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

	16 source types, 18 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) · JavaScript Reader · serial
Destinations: MLLP · TCP · HTTP · SOAP · SMTP · file · FTP · SFTP · S3 · database · DICOM · FHIR · CDA · document · JavaScript · Kafka · message broker (STOMP) · another channel
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 when you need it
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
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: Da Vinci PAS, X12 278, payer FHIR APIs
Submits prior authorisation requests to payer FHIR APIs, which CMS-0057 requires
Maps Da Vinci PAS to and from the X12 278 transaction, so a payer on either side is reachable
Tracks a request through to its determination rather than firing and forgetting

	eCR and ELR
Electronic case reporting (eCR) and electronic lab reporting (ELR)
Reportable-condition triggering, so a message is submitted because it met a rule rather than because somebody remembered

	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
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 a real Mirth
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
And you can export back. A channel built here can be written as a Mirth channel file, and a real Mirth server accepts it. Ten transport pairs verified by importing into a running Mirth
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.

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.

Verify what you downloaded against [SHA256SUMS](https://github.com/biodream-llc/perfuse/releases/download/v0.1.3/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.

# 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

---

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

• 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](/verification/):

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 mirth-channel-export.xml

# 2. Convert it
perfuse translate mirth-channel-export.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](/reference/#migrating-from-mirth) · [Mirth scripts](/reference/#mirth-scripts)

---

Perfuse vs Mirth Connect

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](https://github.com/MichaelLeeHobbs/mirthless/blob/main/docs/design/14-beyond-mirth-competitive-gaps.md): 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:

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

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](/hl7-api/).

---

FAQ

---

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, and forking is disabled on this repository. 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](https://github.com/biodream-llc/perfuse/issues) 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](/releasing/) covers cutting a release and lists what the current one could not verify.

---

Licence

[Apache License 2.0](LICENSE). Copyright 2026 BioDream LLC. See [NOTICE](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.