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.
Sign in as demo with password try-perfuse-demo · test data only · look at every screen, change nothing
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
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 and DICOMweb · X12 837, 835, 270/271, 276/277, 834 and 278 · SMART Health Links and Cards · International Patient Summary · IHE XDS/XDM documents · S/MIME Direct messages · C-CDA and CDA · HL7 v3 · NCPDP Telecommunication, SCRIPT (with ePA) and RTPB · UN/EDIFACT · delimited and raw formats.
How it connects: MLLP, TCP, HTTP, SOAP, files, FTP, SFTP, SMB, WebDAV, databases, DICOM, DICOMweb, Kafka, message brokers, AMQP 1.0 (Azure Service Bus, RabbitMQ 4), MQTT, IBM MQ, Azure Blob Storage, Google Cloud (Pub/Sub and Cloud Storage), AWS — S3, SQS and SNS — IHE XDS.b and XCA, Direct secure messaging, AS2 trading partners, email mailboxes (IMAP and POP3, with Microsoft 365 and Gmail OAuth), immunization registries (CDC IIS) and DICOMweb: twenty-eight source types and thirty-one 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 and a Plan-Net provider directory, with claims as CARIN Blue Button, prior authorisations as Da Vinci PDex and the yearly metrics page. eCR public health case reporting. SQL on FHIR v2 (FHIR as tables, to Parquet), digital quality measures to DEQM MeasureReports, and an MCP server so AI agents can query it under the caller's own role. 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, start-up options included: each perfuse serve flag that turns on a feature is also a setting in the
console, applied at the next restart. That is a rule this project holds itself to, not an aspiration: a feature reachable
only from YAML or the command line is treated as a bug.
- PIX and PDQ in HL7 version 3: with the patient index on,
/pixv3is an IHE PIX Manager (ITI-44 identity feed, with merges; ITI-45 query) and/pdqv3a PDQ Supplier (ITI-47, with continuation and cancel), over SOAP, from the same index as PIXm and$match. The answers validate against IHE's HL7 V3 schemas and answer IHE's own sample messages. - Direct, three more ways: a Direct source reads the address's IMAP mailbox at the HISP and takes XDR (ITI-41 over
SOAP with a Direct addressing block); an
xdsdestination sends XDR withdirect_fromanddirect_to; and recipient certificates are looked up in the domain's LDAP directory when DNS has none. Checked against OpenLDAP, GreenMail, the NIST XDS Toolkit's Document Recipient and ONC SITE's Direct XDR Edge Test Tool (both ways). - Fixed: ONC SITE's XDR validator, the (h)(2) certification reference, faulted on every XDR message Perfuse sent
(its parser cannot read XML that redeclares the default namespace on each element, as Go writes it). Metadata now goes out
prefixed, as in IHE's samples, with
mustUnderstandonwsa:MessageID; SITE answers Success both ways, sending and receiving. - Direct certificate checks, against ONC's Certificate Discovery Tool: a Direct destination now refuses a recipient
certificate revoked on its issuer's CRL and fetches missing intermediates from AIA; the LDAP lookup asks the configured DNS
server and works with ApacheDS; a failed address-bound DNS answer falls back to the domain. All 18 DCDT discovery cases pass
(9 did before). A Direct source also reads SITE's own HISP over IMAP (
imap.tlstrusts a HISP's private certificate). - Fixed: an HTTP source cut the last byte off any body ending in 0x1C (taking it for MLLP framing), which broke one
OpenPGP message in 256 and any other binary body ending that way. An
xdsdestination sent a CDA document's confidentiality as its meaning (normal) instead of its code (N), and codes without a display had no name, which a strict registry refuses. The shared demo account may press the checks that change nothing (a script's Check, the channel editor's validate and parse). The v0.1.17 notes below were relabelled v0.1.18 by the release script, which now leaves "New in" headings alone.
For the UK and Europe, and every screen of the public test server at work.
- The console in twelve languages: English, German, French, Dutch, Spanish, Italian, Portuguese, Polish, Swedish, Danish, Norwegian and Finnish, chosen in the header, with dates and numbers written the locale's way. Every screen in every language is checked by a test that fails on any text left in English; code, messages and anything typed are never translated. The manual is published in the same languages. The translations were made by machine (Llama 3.3 70B) and have not yet been reviewed by native speakers, and each says so.
- National patient numbers: the NHS number (and Scotland's CHI and Northern Ireland's H&C number), PPSN, KVNR, SVNR, AHV,
BSN, the Belgian national register number, the French INS, codice fiscale, DNI/NIE, the Nordic, Baltic and central European
numbers: 37 schemes, each checked by its check digit and stored one way, so an NHS number sent under its OID and under its
FHIR URL is one identifier. A mistyped number is kept but never links two records. HL7 v2
NN<country>andNHtypes are read; numbers are masked below a role an administrator sets. - National code systems: SNOMED CT national editions from their whole RF2 package (the display in the country's language,
every language's terms as designations,
$lookupwithdisplayLanguage); ClaML for WHO ICD-10, ICD-10-GM, OPS and CIM-10 FR; the ICD-11 tabulation and the WHO ICD API; delimited national tables in any encoding; versions in force from an effective date. - GDPR and UK GDPR: a Data protection screen that finds everything held about a person in every store, gives them a copy, erases it with a second administrator's approval, keeps it under a legal hold (which the retention window respects), and re-applies erasures to a restored backup from a ledger of salted hashes. The record of processing (Article 30) from the channels; retention per kind of record; a draft data processing agreement for hosting.
- Data residency:
-residency eea(oruk,ch, region codes) refuses channels whose cloud connectors are elsewhere. OpenTofu for hosting one organisation in Frankfurt, Ireland or London with everything in the Region, with list-price costs. - Fixed on the way: a feed contract beside its channel was listed as a broken channel; a shadow comparison started from
the console never started on a server run as a service; the XDS and DICOMweb connectors sent
${ENV}credentials literally (a DICOMweb source accepted the text${STOW_TOKEN}as its token); a data protection erasure by a bare record number left the patient index record behind. See verification. - The public test server shows every screen at work, with invented data (patients, results, the patient index, imaging, documents, a queue that fills while a receiver is away and drains when it is back, a shadow comparison, data protection requests), and its shared demo account may read the administrators' screens too. Try it.
perfuse generategives small mixed batches every kind of message, and no longer repeats its identifiers between runs.
Clusters, PostgreSQL, the patient index, AS2, OpenPGP, EDIFACT, mailboxes, terminology, SNMP
- Clusters: two or more servers on one PostgreSQL store take over from each other: active-passive (the leader runs
everything) or active-active (channels spread over the servers, moved by hand from the console). Leases measured on
each server's own clock, so no two servers ever run one feed; configuration kept the same on every server through the
store;
/readyz?channel=for the load balancer. Killed with SIGKILL mid-stream in the tests: nothing acknowledged lost. Tested on AWS too: Linux and Windows servers in three zones, Amazon RDS over checked TLS, a Network Load Balancer, a leader cut off from the database and clocks two minutes apart; 16,000 acknowledged messages, none lost. - PostgreSQL for everything: messages, queues, accounts, the audit log, the FHIR store, terminology and the patient
index, with
-db postgres://...; SQLite stays the default for one server. - Master patient index: records from every system linked into one enterprise identifier per person, deterministic
(trusted identifiers) and probabilistic (Fellegi-Sunter, Jaro-Winkler) matching, a review queue, links, unlinks and A40
merges with their history, FHIR
Patient/$matchand PIXm; off until a site turns it on, and automatic linking off until an administrator trusts it (measured on FEBRL: no wrong links), with weights it can estimate from the site's records. - AS2 (RFC 4130): EDI with trading partners over HTTP, signed and encrypted with S/MIME, delivered only when the partner's signed receipt names the digest of what was sent; synchronous and asynchronous receipts; tested against pyas2lib both ways. Compressed messages (RFC 5402) both ways, and a resend of a message already passed on is answered with a receipt and not delivered twice.
- OpenPGP: decrypt and verify what a source receives, encrypt and sign what a destination sends (files, SFTP, S3, email, HTTP), with keys checked when the channel loads; tested against GnuPG in both directions.
- UN/EDIFACT: a data type with envelope checks (UNB/UNZ, UNH/UNT counts), element filters and paths, one message per UNH, and CONTRL acknowledgements; tested against pydifact.
- Mailbox source: IMAP and POP3, with Microsoft 365 and Gmail sign-in by OAuth 2.0; the body or attachments become the messages, then the mail is moved, flagged or deleted; tested against GreenMail.
- Terminology: mapping tables with editions and effective dates (each message uses the edition in force that day),
and an optional second person's approval; values no table maps, counted and listed; LOINC, SNOMED CT, RxNorm,
ICD-10-CM and local code systems imported for search,
CodeSystem/$lookupand$validate-code. - SNMP: a read-only SNMPv2c agent (channel states, message counts, queue depths) and alert traps, with a MIB to download from the console.
- Mirth scripts: JavaScript equivalents of the Java classes Mirth scripts use most, so more of them run unchanged.
- Supply chain:
govulncheckruns in CI and gates every release; Go 1.27.2 and current x/crypto, x/net and x/text.
Sixteen areas. Nothing here is aspirational: where something is partial it says so, and the verification record says what each claim was checked against. The manual covers every one in full.
 Parse, route, transform, generate, acknowledge
|
 R4, R4B and R5: mapper, server, validator
|
 The DIMSE services and DICOMweb, both directions
|
 Claims, payers and pharmacy, parsed as structures
|
 C-CDA and CDA, including the ones inside v2
|
 28 source types, 31 destination types
|
 Declarative steps, or JavaScript or Lua
|
 A durable queue that does not lose messages
|
 Sign-on, roles and channel groups
|
 UDAP, Facilitated FHIR and its auditing
|
 CMS-0057, and drugs for CMS-0062-P
|
 eCR, ELR and immunization registries
|
 Shadow mode, feed contracts, drift
|
 Dashboards, alerts, search, fleet, tenants
|
 Both directions: Mirth 4.5.2, OIE, BridgeLink
|
 An API for everything, and Go libraries
|
 Clusters, PostgreSQL, the patient index
|
 The UK and Europe
|
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.
- 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
test.perfuse.health is a public Perfuse with test data only. Sign in to the console with username
demo and password try-perfuse-demo: it can look at every screen and change nothing. Its FHIR, CRD, DTR, PAS, Bulk Data and
SMART endpoints are the ones Inferno's hosted test kits run against; see deploy/test-instance.
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.18-windows-amd64.zip |
| Windows | ARM64 | perfuse-v0.1.18-windows-arm64.zip |
| macOS | Apple Silicon (M1–M4) | perfuse-v0.1.18-darwin-arm64.tar.gz |
| macOS | Intel | perfuse-v0.1.18-darwin-amd64.tar.gz |
| Linux | x86-64 | perfuse-v0.1.18-linux-amd64.tar.gz |
| Linux | ARM64 / aarch64 | perfuse-v0.1.18-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 / LinuxA 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 buildThe Linux binaries are statically linked and verified to run on Alpine, so they need no glibc and work in
scratch and distroless images.
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.
# 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:2575Everything 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.
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 translateconverts 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 explainreads 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.
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, and DICOMweb both ways (STOW-RS into Orthanc; Orthanc's DICOMweb client searching and retrieving from Perfuse) |
| OHIF | Viewer listing and displaying studies from Perfuse's DICOMweb archive |
| NIST XDS Toolkit | XDS.b ITI-41/18/43 against its Registry/Repository, and its XCA Initiating Gateway against Perfuse's Responding Gateway |
| 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 (hosted, against test.perfuse.health) | SMART App Launch STU2.2 80/80 · Bulk Data 2.0 48/48 · PDex 2.0 payer-to-payer 19/19, coverage 312 + 1 skip · Da Vinci CRD Server 2.2.1 passes · PAS Server 2.2.1 82/84 · DTR Payer Server 2.2.0 43/45 · Plan-Net 1.1.0 199 pass, 10 fail · US Core 6.1.0 FHIR API 323 passing (locally). 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.
# 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.
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-outThen 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 | 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 |
| IHE XDS.b / XCA, Direct, DICOMweb | Built in | Not provided |
| SQL on FHIR, quality measures | ViewDefinitions to Parquet; FHIRPath Measures to DEQM MeasureReports | Not provided |
| AI agents (MCP) | Built-in MCP server under the caller's role | Not provided |
| CMS-0057 and CMS-0062 payer APIs | Patient Access, Provider Access, Payer-to-Payer, Prior Authorization, drug prior authorization (RTPB, SCRIPT ePA, Drug Formulary); 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.
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 | Has it — servers sharing one PostgreSQL store, active-passive or active-active, failover in seconds; tested by killing the server running a feed with SIGKILL, every acknowledged message delivered |
| #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.
| 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.
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.
Two more packages are published on the same terms (standard library only, no engine), so that software working beside Perfuse reads the same data the same way:
github.com/biodream-llc/perfuse/fhir: the FHIR resource model, R4 and R5 serialisation, and validation.github.com/biodream-llc/perfuse/pas: the Da Vinci PAS request reader Perfuse's own PAS server uses: the Claim, its services and their codes, and reference resolution inside the Bundle. A decision service behind-pas-decider-urlreads requests with it.
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, and no plugin ecosystem; a cluster serves one organisation (not yet with
-multi-tenant). 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.
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.
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.
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.
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
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 · DICOMweb · QIDO-RS · WADO-RS · STOW-RS · OHIF
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 · IHE XDS · XDS.b · XCA · MHD · PIXm · PDQm · document registry · document repository · ITI-41 · ITI-18 · ITI-43 · ITI-38
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