Healthcare Middleware Integration Framework

It can do either. Replacing an interface engine is a high-risk project when every interface has to be cut over at the same moment, so most deployments avoid that by migrating interfaces onto the framework incrementally. In that model the framework runs alongside your legacy engine during the transition. New interfaces are built on the framework from the start, and existing ones are moved over one at a time, in an order that makes sense for your organization, for example starting with a lower-risk interface to validate the approach. Each migrated interface is tested before it is switched, and the legacy engine continues to serve the interfaces that have not yet moved, so there is never a single cutover day on which every connection depends on a new system working perfectly. Some organizations decide to retire the legacy engine once everything has moved, while others keep it for specific interfaces and use the framework for new work. Either approach is workable because the framework is protocol-agnostic: HL7 v2/v3, FHIR R4 and DICOM all route through the same layer, and new connections are added as mapping rules rather than new codebases. Which path is right for you depends on how many interfaces you run, how critical they are and what your current engine's licensing looks like. That is scoped during the Fit Assessment, and the staged go-live comes with monitoring and a rollback plan.

Messages are not lost. When a downstream system cannot be reached, whether because of an outage, a maintenance window or a network problem, the framework retries delivery automatically on a configurable retry policy. That policy lets you decide how persistent the framework should be for each interface, because the right behavior for a lab result feed is not necessarily the right behavior for a low-priority notification. If delivery still fails after the retries are exhausted, the message is placed in a dead-letter queue for review instead of being dropped. A dead-letter queue is a holding area for messages that could not be delivered, so a person can see what failed, understand why and decide how to resolve it, for instance by correcting a mapping problem or re-sending once the destination is back. This matters clinically. In many point-to-point integrations, a failed message simply disappears and the problem only comes to light when a clinician or department notices that a result never arrived. Combined with the real-time monitoring dashboard, which tracks failure rates and latency per interface, and with alerting on thresholds you configure, the team can see a problem developing and respond to it before it becomes a clinical data gap. The retry policy and alert thresholds for each interface are configured during the Configuration and Mapping step of the deployment path.

Yes. The framework includes a real-time monitoring dashboard that tracks message volume, failure rate and latency for each interface, so you can see how every connection is performing at a glance rather than reading through log files. Metrics are reported per interface, which matters because an average across all interfaces can hide a single failing connection. A lab results feed that has stopped delivering would be visible on its own line instead of being diluted by thousands of healthy messages elsewhere. Alerting is available on thresholds that you configure, for example a failure rate above a level you consider acceptable, or latency beyond what a downstream system can tolerate. That turns monitoring from something someone has to remember to check into something that tells the right people when attention is needed. The dashboard works together with the retry and dead-letter handling. Failures that are retried successfully show up as part of the picture of an interface's health, and messages that end up in the dead-letter queue are visible for review. The aim is that interface problems are noticed early, before they become a clinical data gap, rather than after a department calls to ask why results never arrived. Which interfaces matter most, and which thresholds fit them, are decisions made with your team during configuration and tested before go-live.

Yes. DICOM traffic routes through the same protocol-agnostic engine as HL7 v2/v3 and FHIR R4, so imaging integrations do not need a separate toolchain. This matters because many health systems end up running different tools for different standards: one for clinical messaging between the EHR and lab systems, another for imaging, and a third for newer FHIR-based connections. Each tool has its own monitoring, its own failure handling and its own people who know how it works. Putting all three standards through one engine means imaging connections are configured with the same visual mapping and transformation rules as any other interface, benefit from the same retry and dead-letter handling, and appear on the same real-time monitoring dashboard. Mapping and routing changes for imaging interfaces also go through the same versioned change log, so they can be traced, reviewed and rolled back independently, just like the rest. In terms of transport, the framework supports MLLP for HL7 v2 traffic alongside REST and HTTPS for FHIR endpoints, covering the patterns that EHRs and lab and imaging systems commonly use. For your own environment, the specific imaging systems you need to connect, and the way messages should be routed between them and your EHR, are mapped during the Fit Assessment and validated against test traffic before anything goes live.

Every mapping and routing change is versioned with a change log, so the history of a specific interface can be reviewed and rolled back independently of the others. In many integration environments mapping logic lives in custom scripts, and the only record of a change is whatever the engineer remembers or wrote in a commit message. When something breaks months later, nobody can say what changed, when or why. Here, mapping and transformation rules are configured visually and every modification is recorded, which gives you a trail of what was altered and the ability to see how an interface looked before a change was made. Because versioning is per interface, a change to one connection does not force a rollback of unrelated work. If an update to a lab results interface causes a problem, that interface can be returned to its previous version while the rest of the engine carries on routing messages. The change log also supports review practices that many organizations already have: a proposed mapping change can be examined before it goes live, and a past change can be traced during an audit or an incident investigation. This removes the dependency on a single engineer's knowledge, since the rules and their history are visible to the team. How change approval should work in your organization can be discussed during the Fit Assessment and set up during configuration.