Open-source integration for many standards and connections — with the tooling to match
A focused healthcare interface engine that connects a wide range of systems and message standards. Set up connections and routes with guided wizards, or extend them in Python — your choice. Durable delivery; deep HL7 v2 support; active-passive high availability; PHI-aware security; and an admin console plus VS Code tooling. Everything here ships in Early Access; what's coming next is at the bottom of the page.
Your integration logic is yours
AGPL-licensed and open: your configuration is yours — generated by wizards or written in plain Python, versioned in your git repository, running on standard databases. Nothing is locked inside a vendor's runtime, language, or contract.
- AGPL-3.0-or-later — read it, run it, fork it. A low-cost commercial edition is available when the AGPL doesn't fit.
- Configuration as code (or data) — wizards generate it or you write it; either way Connections, Routers, and Handlers are diffable, reviewable modules, and connection settings can also live as data in
connections.toml— edited by hand, with themessagefoundry connectionCLI, or in the VS Code editor. The database holds runtime state and messages only, never configuration. - Standard databases — no proprietary data platform required, and no proprietary scripting language to staff for.
- No runtime or contract lock-in — self-hosted, on your infrastructure, on your terms.
Durable by construction
A durable, transactional inbox/outbox is the reliability backbone — no separate broker to run, patch, or monitor.
- Durable before it's acknowledged — the inbound is ACKed only after the received message is committed to the store on ingest, so an accepted message survives a crash before any processing begins.
- Reliable delivery — every accepted message is persisted and delivered; nothing is silently dropped.
- Ordered (FIFO) delivery — messages to a given destination are delivered first-in, first-out, preserving per-connection sequence.
- Per-outbound workers — each destination drains independently; one slow or failing peer never blocks the others.
- Automatic retries with a configurable failure policy — back off and retry, then dead-letter, with a bulk-replay view for recovery.
- Replay — re-drive a stored message through delivery from the console or API.
- Automatic crash recovery — after a restart or crash, in-flight messages resume from the durable store with no manual cleanup.
- Nothing silently dropped — every message is persisted on ingest, then processed to a recorded disposition (routed, filtered, or unrouted), so nothing is ever quietly discarded.
Deep HL7 v2 — and the formats around it
HL7 v2 is the format MessageFoundry parses and validates in depth. JSON, XML/SOAP, X12/EDI, database records, and other payloads are routed, transformed, and delivered alongside it — moved through your interfaces flexibly, without assuming a rigid schema. MessageFoundry is more than an HL7 interface engine.
- HL7 v2, deeply parsed — full parsing and validation: fast and tolerant on the hot path, strict and version-aware where you opt in. Real-world HL7 is frequently non-conformant, and the engine is built to expect that.
- JSON, XML/SOAP, X12/EDI, database records, and arbitrary payloads — routed, transformed, enriched, and delivered with the full power of Python (a ready X12 codec, a FHIR codec with FHIRPath, one-call JSON parsing, your own library for the rest). HL7 v2 is the one with a structured, standard-aware transform model built in — a difference in built-in support, not in what's possible.
- XML parsing is hardened — XML payloads are read with an XXE-safe parser, so a hostile document (external entities, embedded DOCTYPE, billion-laughs expansion) is rejected, not parsed.
- Encoding read from the message — for HL7 v2, the field, component, repetition, escape, and subcomponent separators come from MSH, never hardcoded.
- Raw message preserved alongside the transformed form, so an operator always sees exactly what arrived.
- Parse failures are isolated — routed to the error / dead-letter path and logged, so a bad message never takes down the connection.
Connect the systems you already run
Inbound and outbound connectors for the transports healthcare actually uses — registered through one contract, not special-cased in the pipeline.
Network
MLLP — correct 0x0B … 0x1C 0x0D framing, inbound and outbound, with ACK/NAK generation (AA / AE / AR) and a per-connection ack mode. TCP for raw stream endpoints. X12 / EDI over TCP — ISA/IEA-framed interchanges, inbound and outbound. DICOM imaging — C-STORE SCP/SCU and C-ECHO over DIMSE, plus DICOMweb STOW-RS (DICOM imaging →).
Web services
HTTP / REST, SOAP, and FHIR REST web-service destinations — deliver to modern and legacy APIs; the FHIR destination does create / update / transaction against R4B (R5 / STU3). Inbound REST / SOAP / FHIR listener endpoints are on the roadmap.
Files & databases
Files — local directories and remote SFTP / FTP / FTPS, with templated output names (e.g. {MSH-10}.hl7). Database — poll records in and write results out.
Count-and-log invariant. Every message a connection takes in or puts out is counted and logged — a router or filter decision is a recorded outcome (UNROUTED / FILTERED), never a silent drop.
Route, filter, and transform — wizards or code
Set up routing and transformation with guided wizards, or write it in Python for full control — no proprietary DSL to learn. Send each message to one destination or many, filter what shouldn't flow, and reshape it on the way through.
- One-to-many routing with filtering — fan a message out to multiple destinations, or filter it out entirely; every decision is a recorded outcome.
- Transform, enrich, validate — reshape and augment messages mid-flight, with validation where you want it.
- Reference & lookup tables and live database lookups — enrich from static tables or query a live database during processing.
- Guided wizards or pure functions — New Connection / New Route wizards generate the wiring, or write Routers and Handlers as plain functions registered by name.
- Dry-run with before/after diff — preview a route's effect on a real message before it ships.
PHI is a first-class concern
This engine carries PHI, so authentication, authorization, audit, and encryption-at-rest are built in — not bolted on. The API binds 127.0.0.1 by default and requires authentication.
- Authentication — local accounts with built-in, required multi-factor authentication (MFA), or Active Directory (LDAP) sign-in, with opaque, revocable sessions.
- RBAC — fixed built-in roles, deny-by-default, per-route and per-channel scoping.
- TLS in transit, by default — the API and MLLP run over TLS (including MLLP-over-TLS); for endpoints that can't do TLS, plaintext is supported within your secure network perimeter.
- Tamper-evident audit log — a hash-chained, user-attributed record of every PHI access (raw view, summary, replay), with a verification command.
- Off-box log & audit forwarding — operational and audit logs forward to your syslog or SIEM collector.
- Encryption at rest — message bodies are encrypted with AES-256-GCM in the store.
- Retention & purge — keep messages as long as policy requires, then purge on a configurable schedule.
A console and an editor, both talking to one API
Admin console
Dashboards, message search and browse, an HL7 parse-tree viewer, delivery and audit trail, a dead-letter page, an alert-rules view, and one-click replay. A separate app that reaches the engine only over the localhost API.
VS Code extension
Author and operate interfaces in your editor: completion, live HL7-aware validate-on-save, a graph view of your integration (a boxes-and-arrows diagram), source-control integration, and Stage → Promote to a running engine.
CLI & localhost API
messagefoundry serve runs the engine and exposes connection control, message search/detail, replay, stats, and a live WebSocket feed. check gates commits; generate produces synthetic, PHI-free HL7.
Alerting & operational niceties. Alerting via webhook and email when a connection stalls or a message dead-letters; a Prometheus / OpenTelemetry /metrics endpoint to scrape engine and connection metrics into your monitoring stack; configuration hot-reload and environment promotion (DEV/PROD values layer over the same modules); configurable ACK modes, message-size and segment guards; and a synthetic HL7 generator for testing — all included.
Wizards and a PHI-safe AI assistant lower the barrier
Power without the blank-page tax — guided generation and AI help that never sees a message body.
Setup wizards
Guided New Connection and New Route flows that generate the Python for you — Corepoint-style guided authoring, but the output is plain code you own and review.
PHI-safe AI assistance
An in-editor assistant governed by a central, environment-aware policy that sends only code, never message bodies, gated by role-based access control.
AI-assisted migration
Moving from another engine is AI-assisted by design: paste your existing Mirth / Cloverleaf / Rhapsody logic and the assistant helps you express it as Python — typically far less effort than re-platforming. Code-only and governed.
A full test harness, included
Exercise interfaces with synthetic, PHI-free traffic before anything touches production — interactively or in CI.
- Send / receive / file / compose / monitor test bench for driving inbound and outbound endpoints by hand.
- Headless scenario runner for CI — assert routing and transform behavior on every commit.
- Test Bench dry-runs in VS Code — run
.hl7files through a route with before/after diffs. - Synthetic HL7 generator — realistic, PHI-free messages for load and edge-case testing.
checkcommit gate — validate configuration before it ships.
Ships through the pipeline you already run
Because interfaces are plain Python in your git repository, they move through the same delivery pipeline as the rest of your software — no vendor deployment tool to learn.
- Pull-request review — every interface change is a readable diff your team approves, with full history and instant rollback.
- A build gate —
messagefoundry checkvalidates config and dry-runs messages, failing the build on a broken route before it merges. - Automated tests in CI — a headless scenario runner asserts the engine's outcome on synthetic data, pass/fail, in GitHub Actions, GitLab CI, Jenkins, or Azure DevOps.
- Reproducible promotion — only a reviewed, green change is promoted to each environment, so production matches git — no config drift.
- Auditable by default — reviewed, tested, timestamped change control, the way compliance already expects it.
From a single file to a highly available database
One pluggable message store behind a single contract, so the database is a deployment choice — not a code change. Start zero-config on SQLite, then move to PostgreSQL or SQL Server for highly available production with failover.
SQLite
The zero-config, single-node default — WAL, one file, no server to run. The "it just works" path for development, demos, embedded use, and small single-box sites — and the byte-identical baseline every other backend matches.
PostgreSQL
The production server DB for high availability: a standby shares the same store and takes over on primary failure via leader election, preserving strict per-destination FIFO ordering. The reference production backend.
SQL Server
A first-class production backend at parity with PostgreSQL — the same staged pipeline, concurrency-safe claiming, row leases, and high-availability failover — for shops standardized on SQL Server.
One Store contract. The same staged-pipeline delivery model — dispositions, retries, replay, audit, encryption at rest, and configurable retention/purge — runs across all three backends. PostgreSQL and SQL Server are interchangeable production server-DBs, so you pick whichever your environment already runs. No proprietary data platform required; your messages live in a database you control.
Stay up through failures
Run a primary with a hot standby: if the primary fails, the standby takes over with no message loss. The data tier rides your database's own HA — PostgreSQL replication or SQL Server Always On.
- Active-passive failover — a standby promotes on primary failure; in-flight work resumes from the durable store.
- No message loss — failover picks up from committed state, so nothing accepted is dropped.
- Database-tier HA — PostgreSQL streaming replication or SQL Server Always On availability groups back the store.
- Runs in your environment — on-premises, on your infrastructure, on your DR terms.
Runs headless, where your data lives
On-premises by default — no PHI leaves the local environment without explicit, reviewed configuration.
- Windows service via NSSM — install/uninstall scripts included.
- Headless engine — no GUI imports; testable and runnable as a service.
- One config, many environments — DEV/PROD values layer over the same Python modules.
Possible future additions
Everything above ships in Early Access. Here's where MessageFoundry is headed next.
Connectivity & standards
Inbound REST, SOAP, and FHIR listener endpoints; OAuth 2.0, SMART on FHIR, and single sign-on (OIDC/SAML, AD FS/Entra ID, and passwordless Windows/Kerberos); and more databases — MySQL/MariaDB and Oracle.
Security & operations
A multi-engine console view, and an independent external code review and penetration test.
Frequently asked questions
Does MessageFoundry support HL7 v2 and FHIR?
Yes. MessageFoundry has deep HL7 v2 support — parsing, validation, routing, and transformation — and works with FHIR, alongside X12/EDI, DICOM, JSON, and XML payloads.
What systems and protocols can MessageFoundry connect?
It connects the systems you already run over MLLP (with TLS), TCP, HTTP/REST, SOAP, FHIR REST, files, SFTP/FTP, databases, and DICOM — so a wide range of protocols and message types flow through one engine.
Do I write interfaces in code or with a GUI?
Both. You can set up Connections, Routers, and Handlers with guided wizards in the VS Code extension and admin console, or write them in plain Python for full control — version-controlled like any codebase.
Is MessageFoundry built for PHI and security?
Yes. PHI is a first-class concern: it stays self-hosted, traffic is encrypted with TLS, message bodies at rest with AES-256-GCM, every operator is authenticated, and access is audited. It's built to NIST SSDF / 800-66 and self-assessed against OWASP ASVS Level 3.
How does MessageFoundry scale?
MessageFoundry scales horizontally by adding interfaces. The unit of capacity is one inbound interface, which sustains roughly 50 messages per second in our measurements — on the order of a million messages a day — with strict in-order, durable, at-least-once processing, so messages aren't silently dropped. That is well beyond what a single hospital's routine ADT feed needs, with comfortable headroom for bursts. When you need more, you split feeds at the source across more interfaces and aggregate throughput is the sum across them, plus an optional multi-node tier. These figures are measured on anonymized, representative message traffic; real throughput depends on your transforms, storage, and hardware.