Most conversations about healthcare integration architecture reach the wrong level of abstraction too quickly. They debate standards before they have resolved topology, or they optimise messaging throughput before they have agreed on who owns the canonical data model. The result is integration infrastructure that is technically functional but architecturally fragile: systems connected by point-to-point dependencies that multiply with every new service, or middleware layers that become single points of failure because no one made a deliberate decision about how much work they should do.
Getting the architecture right requires working through three questions in sequence. What topology should govern how systems relate to one another? Which pattern should govern how events flow through that topology? And what role should middleware and integration engines play in managing both?
Point-to-Point Integration and Its Costs
Point-to-point integration is where most healthcare organisations start, and where many become stuck. One system needs data from another, a direct connection is built, and the integration works. Each new integration in a point-to-point mesh creates a bilateral dependency: the source system needs to know the target system exists, and the target system needs to know the format the source system produces.
In practical terms, a healthcare environment with six systems can require up to fifteen separate connections to achieve full interoperability. Adding a seventh requires up to six more. That combinatorial growth is exactly what produces the integration debt accumulating in most NHS trusts over a decade of incremental procurement decisions. The connections are undocumented, transformation logic is embedded in custom code at each endpoint, and the operational team inherits a topology that nobody consciously chose.
Hub-and-Spoke Architecture and Integration Engines
Hub-and-spoke architecture addresses the combinatorial problem by introducing a central integration layer that brokers all communication. Each system connects to the hub rather than to every other system directly. Message transformation, routing, protocol mediation, and error handling are owned by the hub rather than distributed across endpoints. Adding a new system requires one connection, not connections to every existing participant.
Healthcare integration engines such as Mirth Connect, Rhapsody, and Azure API Management implement this model with domain-specific capabilities. They understand HL7 v2, FHIR, DICOM, and NHS-specific messaging formats, and they make the integration layer operationally visible in a way that point-to-point code cannot be. For organisations moving from HL7 v2 toward FHIR R4, an integration engine provides the mediation layer that allows both protocols to coexist during transition rather than forcing a hard cutover.
The risk is that the hub becomes a bottleneck and a single point of failure. If a single integration engine goes offline, every connected system loses interoperability simultaneously. The architectural response is a highly available hub configuration with active-passive or active-active failover, and downstream systems designed to tolerate transient unavailability rather than assuming synchronous delivery.
Event-Driven Architecture in Healthcare Integration
Event-driven architecture decouples producers from consumers by routing all communication through a durable message broker rather than direct synchronous calls. A system recording a new admission publishes an event to the broker. Every system that cares about admissions subscribes and processes it independently. Producers have no visibility of which systems are listening, and consumers process events regardless of when they were produced.
Clinical state changes such as a discharge, a new diagnosis, or a medication order are naturally modelled as discrete events with clear semantics. Multiple downstream consumers including the GP system, the pharmacy, the patient record, and the care plan service can all react to the same event without the originating system orchestrating the fan-out. Audit trails become complete by construction: the event log is an immutable record of everything that happened, in sequence, with timestamps that survive any downstream system failure.
Azure Service Bus provides durable queuing with dead-letter handling and session-based ordering for multi-step workflows. Apache Kafka supports high-throughput event streaming for population health pipelines. Both integrate with FHIR subscription mechanisms so clinical systems publish FHIR-compliant change notifications without bespoke transformation. One constraint is that all participating systems must produce well-formed events and consume idempotently. Legacy systems often need an adapter layer at the boundary to meet that contract.
Middleware, Orchestration, and Microservices Modernisation
Middleware, in the form of an integration engine or message broker, owns the transport and routing layer: protocol translation, schema contract enforcement, and the operational visibility needed to diagnose failures. Microservices own the business logic layer: validation, transformation, reconciliation, and workflow orchestration once a message has arrived.
Replacing monolithic integration code with small, independently deployable services reduces the cost of change. A validation rule that previously required a full integration engine deployment can be updated by deploying a single container. The tradeoff is operational complexity: container orchestration, service discovery, and distributed tracing all require investment a single integration engine does not. What makes healthcare integration particularly demanding is that the correctness bar is higher than in most domains. A misconfigured retry policy in a clinical messaging context can produce duplicate medication orders or conflicting demographic records.
Our Expertise
We design and deliver integration and interoperability solutions that work across topology, eventing pattern, and middleware orchestration. Our work covers event-driven architectures on Azure Service Bus, API gateway design with Azure API Management and OAuth2, HL7 FHIR R4 implementation, and the compliance posture including DSPT, DTAC, and DCB0129 that NHS programmes require from day one.
See It in Practice
A UK healthcare services provider needed to connect a long-established, heavily customised NAV-based ERP to external and national-level services without a disruptive replacement programme. The platform was stable but its integration options were limited, and any change carried significant clinical and operational risk.
We delivered a decoupled, event-driven architecture on Azure: API Management as the governed gateway, Service Bus as the messaging backbone with durable queuing and dead-letter handling, and containerised .NET services orchestrating validation, patient matching, and idempotent write-back to the ERP. The result was an integration layer that could absorb new use cases without touching the legacy system, with full audit trails and correlation IDs satisfying clinical governance requirements throughout.
Read the full case study → Legacy Healthcare ERP Integration on Microsoft Azure
