Interface Build and FHIR
New interfaces on the engine you already run
Interface requests do not stop while the licensing question is being settled. We build new interfaces on the Mirth Connect release or fork you run, in the same style as the rest of your estate so your team can own them afterwards.
What we build
- HL7 v2 feeds over MLLP and files: ADT, ORM and ORU, SIU, DFT and the site-specific Z-segments that come with real EHRs and lab systems.
- CCDA and other document exchange, including parsing, section extraction and routing.
- X12 transactions for billing and payer connections.
- DICOM routing and imaging-adjacent messaging.
- Flat files, databases and REST or SOAP APIs where a vendor offers nothing else.
FHIR enablement
CMS-0057-F puts FHIR API obligations on regulated payers, with compliance dates in 2026 and 2027, and providers face their own API requirements. In most organisations the data behind those APIs still arrives as HL7 v2 through the integration engine. We map v2 segments to FHIR resources (Patient, Encounter, Observation, Coverage and the rest), decide which identifiers and code systems carry across, and build the channels that feed your FHIR server or API layer.
How each interface is designed
- ACK and NACK behaviour agreed with the partner system, including what the sender should do on an application reject.
- Error handling and queueing chosen per destination, with retries that do not flood a partner that is down.
- Alerting that fires on silence as well as on errors.
- Throughput tested against realistic peak volume before go-live.
- Validation against test messages from the partner, connectathon-style, before production traffic.
Chartferry is independent. We are not affiliated with, endorsed by, or a reseller of NextGen Healthcare, and we use the name Mirth Connect only to describe the product we work on.