Route, transform, and operate healthcare interfaces
Connect healthcare systems with guided wizards or Python. MessageFoundry includes durable delivery, deep HL7 v2 support, a browser console, and VS Code tools. These capabilities describe Early Access; future additions appear below.
Your integration logic is yours
Keep wizard-generated or handwritten configuration in your Git repository. The engine is AGPL-licensed and runs on standard databases.
- AGPL-3.0-or-later — read it, run it, fork it. A low-cost commercial edition is available when the AGPL doesn't fit.
- Connections, Routers, and Handlers are reviewable modules, generated by wizards or written by hand. Connection settings can also live in
connections.toml. Edit that file directly, throughmessagefoundry connection, or in VS Code. The database holds runtime state and messages, not configuration. - Choose SQLite, PostgreSQL, or SQL Server for the message store.
- Run the engine on your own infrastructure.
Store messages through processing and delivery
A transactional inbox and outbox store messages through processing and delivery. No separate message broker is required.
- The engine acknowledges an inbound message after committing it to the store. Accepted messages survive a crash before processing starts.
- Accepted messages are stored and tracked through delivery or a recorded outcome.
- 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.
- Each message reaches a recorded outcome, including routed, filtered, or unrouted.
Deep HL7 v2 — and the formats around it
MessageFoundry parses and validates HL7 v2 in depth. It also routes, transforms, and delivers JSON, XML/SOAP, X12/EDI, database records, and other payloads. Read about message formats →
- HL7 v2 parsing tolerates non-conformant messages. Enable strict, version-aware validation for feeds that need it.
- Route, transform, enrich, and deliver JSON, XML/SOAP, X12/EDI, database records, and other payloads in Python. Built-in helpers include an X12 codec, FHIR with FHIRPath, and JSON parsing. Use your own libraries for other formats. HL7 v2 includes a structured transform model based on the standard.
- 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
Connectors use a shared contract to receive and send messages through 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.
Each inbound and outbound message is counted and logged. Routing and filtering record an outcome, including UNROUTED or FILTERED.
Route, filter, and transform — wizards or code
Use wizards or Python to route, filter, and transform messages. Send to one or more destinations and record each outcome.
- 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.
Protect patient data and control access
Authentication, access controls, audit records, and encryption help protect patient data. The API binds to 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
View dashboards, search messages, inspect HL7 fields, and review delivery and audit records. The console also includes dead letters, alert rules, and replay. It connects through the engine’s local API.
VS Code extension
Use field completion, HL7 validation on save, a graph view, and source control in VS Code. Stage and promote reviewed configuration 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.
Webhook and email alerts report stalled connections and dead-lettered messages. Export metrics through /metrics to Prometheus or OpenTelemetry. Hot-reload configuration and promote it between environments. Configure acknowledgement modes, message-size limits, and segment guards. Generate synthetic HL7 for testing.
Use wizards and optional AI assistance
Generate configuration with wizards or use the optional assistant to draft code for review.
Setup wizards
The New Connection and New Route flows generate Python configuration you can review and edit.
Optional AI assistance
The editor sends code and configuration names to your provider. Keep patient data and secrets out of that context. Central policy and roles control access.
AI-assisted migration
Open existing Mirth, Cloverleaf, or Rhapsody logic to draft a Python version. Review the draft and compare outputs before cutover.
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
Keep Python interfaces in Git and use your existing review, test, and deployment tools.
- Review interface diffs in pull requests. Use version history to trace changes and restore earlier configuration.
- 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.
- Promote the reviewed configuration to each environment. Keep production configuration aligned with Git.
- Keep timestamped records of reviews, tests, and deployment changes.
From a single file to a highly available database
Start with SQLite or choose PostgreSQL or SQL Server for a server-backed store. All three use the same store contract.
SQLite
SQLite is the single-node default. It uses write-ahead logging and one database file, with no separate server. Other backends are checked against its behavior.
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
SQL Server supports the same staged pipeline, concurrent work claiming, row leases, and failover as PostgreSQL.
All three backends support recorded outcomes, retries, replay, audit, encryption at rest, and configurable retention and purge. Choose PostgreSQL or SQL Server for production with a shared server database.
Stay up through failures
Run a primary with a hot standby: if the primary fails, the standby takes over without losing in-flight messages. 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
The items below are outside the Early Access feature set.
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?
MessageFoundry authenticates operators, audits access, and encrypts traffic with TLS and stored message bodies with AES-256-GCM. Its security work includes NIST mappings and an OWASP ASVS Level 3 self-assessment.
How does MessageFoundry scale?
A single interface measured about 50 messages per second on anonymized, representative traffic, with durable, ordered delivery. Actual capacity depends on your workload, partner response times, storage, and hardware. Interfaces share resources, so their measured capacities do not simply add together. Read the sizing guide →