More than just an HL7 interface engine
Yes, MessageFoundry is a capable HL7 interface engine — with deep HL7 v2 parsing, validation, routing, and transformation. But it's a full healthcare interface engine: the same engine connects FHIR, X12/EDI, and DICOM across a wide range of transports — open-source, self-hosted, and written in Python.
MessageFoundry as an HL7 interface engine
An HL7 interface engine receives, routes, transforms, and validates HL7 v2 messages between clinical systems — the EHR, lab, radiology, pharmacy, and billing — so they exchange data reliably. MessageFoundry does exactly that, self-hosted and in plain Python over MLLP, and the same engine also speaks FHIR, X12, and DICOM.
An open-source HL7 interface engine
MessageFoundry is an open-source HL7 interface engine — licensed under the AGPL and self-hosted, so PHI stays on your own infrastructure and there's no per-interface licensing. It's an open alternative to the proprietary, paid engines: Mirth's open-source line has ended, while Corepoint, Rhapsody, and Cloverleaf are commercial. It's also far younger than any of them — MessageFoundry started in May 2026 and is in Early Access. Why self-hosted & PHI-safe →
A capable HL7 v2 engine
If you came looking for an HL7 interface engine, you're in the right place. MessageFoundry does the classic HL7 v2 work, and does it well:
- Receive and send over MLLP (with MLLP-over-TLS), TCP, and files.
- Tiered validation — tolerant peek, strict structural, and cross-field business checks.
- Route, filter, and transform in plain Python, addressed by HL7 path (
MSH-9.1,OBR-25, …).
…and a broad healthcare interface engine
The same engine, the same Python config, reaches well past HL7 v2:
- FHIR — deliver resources and Bundles to a FHIR server over REST (R4B/R5/STU3).
- X12/EDI and DICOM imaging alongside HL7 — no separate tool per standard.
- Many transports — HTTP/REST, SOAP, SFTP/FTP, and databases, plus JSON and XML payloads.
One engine, every interface. The reason "HL7 interface engine" undersells it: healthcare integration rarely stops at HL7 v2. MessageFoundry connects a wide range of protocols and message types from a single open-source, self-hosted, Python-native engine — so HL7 and everything around it run side by side, version-controlled like any codebase. See how that compares to legacy engines →
Related guides
Frequently asked questions
Is MessageFoundry an HL7 interface engine?
Yes — and more. MessageFoundry has deep HL7 v2 support: parsing, tiered validation, routing, and transformation over MLLP. It is also a broader healthcare interface engine that connects FHIR, X12/EDI, and DICOM across many transports — so one engine handles HL7 and everything around it.
What does MessageFoundry support besides HL7 v2?
FHIR (REST), X12/EDI, and DICOM, plus JSON and XML payloads — over MLLP, TCP, HTTP/REST, SOAP, files, SFTP/FTP, and databases. It connects a wide range of healthcare protocols and message types from a single, self-hosted engine.
Is MessageFoundry an HL7 interface engine or a healthcare interface engine?
Both terms fit. MessageFoundry handles classic HL7 v2 interfaces and the broader integration work — FHIR, X12, DICOM — in one open-source, self-hosted, Python-native engine, so you don't need a separate tool per standard.
What is an HL7 interface engine?
An HL7 interface engine is software that connects clinical systems by receiving, routing, transforming, and validating HL7 v2 messages between them — for example moving an ADT or ORU message from the EHR to a lab or billing system. MessageFoundry is a self-hosted, Python-native HL7 interface engine that also handles FHIR, X12, and DICOM.