Common Healthcare Integration Patterns: A CTO's Guide to Choosing and Mixing Architectures

Healthcare integration rarely follows a single architectural pattern. In real enterprise environments — hospitals, integrated delivery networks, HIEs, payers and digital-health vendors — the interoperability layer is almost always a hybrid, blending several approaches according to the age of the systems involved, the volume and latency of the data, and the degree of standardization achievable across trading partners. Getting that blend right is a strategic decision, not a technical afterthought: the West Health Institute's widely cited analysis estimates that a lack of interoperability costs the U.S. health system over $30 billion a year in redundant tests, administrative waste and delayed care.

This insight article examines the four healthcare integration patterns that dominate modern interoperability architecture — point-to-point interfaces, hub-and-spoke integration engines, event-driven messaging, and API-first FHIR — with the trade-offs an architect should weigh before committing. It assumes familiarity with HL7 v2, FHIR, MLLP and message brokers, and focuses on design-level decisions rather than implementation.

1. Point-to-Point Interfaces

The point-to-point (P2P) interface is the oldest and fastest pattern to stand up: System A connects directly to System B, typically over an HL7 v2 MLLP feed. For one or two stable interfaces it is the most cost-effective option, with the shortest, most predictable data path and no middleware overhead.

The problem is combinatorial. The number of connections needed to fully mesh n systems grows as n(n-1)/2 — 10 systems require 45 interfaces, 15 systems require 105. Each connection must be individually secured, monitored and maintained, and each often ends up "owned" by the developer who built it, so institutional knowledge walks out the door when they leave. This is the classic engine of integration technical debt.

• Best fit: A small number of stable, low-change interfaces; low-latency links to legacy systems whose APIs are too limited for middleware.
• Key risk: Unmanageable quadratic growth, no central monitoring, and brittle, undocumented connections that accumulate as technical debt.

2. Hub-and-Spoke Integration Engines

The hub-and-spoke model collapses that quadratic mesh into a linear one: every system connects once to a central integration engine, reducing total interfaces from n(n-1)/2 to n. The engine becomes a mediation layer that decouples senders from receivers and provides message transformation, routing, filtering, auditing and error handling at a single, governable chokepoint. It is the default pattern for virtually all mid-to-large hospital deployments.

The most widely deployed engine in U.S. healthcare is Mirth Connect (now NextGen Connect), alongside commercial options such as Rhapsody, InterSystems and Cloverleaf, and cloud-managed offerings like Azure Health Data Services. Architects should note a recent market shift: on March 19, 2025, NextGen Healthcare announced Mirth Connect was transitioning from a dual open-source/commercial license to a single, closed-source, proprietary model beginning with version 4.6, leaving version 4.5.2 (released September 2024) as the last freely available open-source release. The change has spawned two community open-source forks — Open Integration Engine and BridgeLink — and should factor directly into any long-term engine-selection or migration decision [3].

• Best fit: Any environment with more than two or three systems exchanging data; hospitals routing ADT, ORU, ORM, SIU and DFT feeds among EHR, LIS, RIS, pharmacy and billing.
• Key risk: The engine is a single point of failure and a concentration of operational responsibility; it demands a mature team and a real high-availability strategy. Vendor licensing and lock-in are now first-order concerns.

3. Event-Driven Messaging via Message Brokers

When volume and fan-out dominate, a durable message broker such as Apache Kafka shifts the architecture from request-driven mediation to event-driven architecture in healthcare. Kafka's publish-subscribe model decouples producers from consumers: a single event — say, an ADT^A01 admission — is written once to a topic and independently consumed by many downstream systems (census, labs, pharmacy, care management, analytics) without the producer knowing or waiting for any of them. Because Kafka stores events durably in an ordered, replayable log, consumers can re-read history, and the cluster scales horizontally for high throughput and fault tolerance [4].

This pattern shines for real-time ADT broadcasting, lab-result distribution across large networks, remote patient monitoring and device telemetry. A flagship public example is the U.S. CDC's COVID-19 Electronic Lab Reporting (CELR) system, built on Kafka and, in the words of Confluent's Kafka Summit case study, "established to rapidly aggregate, validate, transform, and distribute laboratory testing data submitted by public health departments and other partners" — operating at national scale across dozens of U.S. jurisdictions [5].

• Best fit: High-volume, one-to-many real-time distribution; decoupled microservice ecosystems; replay and audit requirements.
• Key risk: Operational complexity is significant; a broker is overkill for a single interface and requires strong platform-engineering maturity, schema governance and monitoring.

4. API-First Integration with RESTful FHIR

The newest and increasingly preferred pattern for greenfield interoperability is API-first design built on HL7 FHIR RESTful endpoints. FHIR represents clinical and administrative data as typed resources (Patient, Observation, Encounter, MedicationRequest) exchanged over standard HTTP interactions, making it the natural fit for patient-engagement apps, analytics tools and third-party vendors that need on-demand access to clinical data without a dedicated HL7 interface engine [1].

Regulation has accelerated this shift. Under the ONC Cures Act Final Rule, since January 1, 2023, all certified EHR users are required to have standardized FHIR APIs for patient and population services available to exchange data with patients and authorized business partners. Adoption has followed: per the 2024 AHA IT Supplement reported by ASTP/ONC, 81% of U.S. hospitals enabled patient access using apps meeting API specifications and 70% enabled access via apps meeting HL7 FHIR specifications [2]. Crucially, FHIR is largely being added alongside HL7 v2 rather than replacing it — v2 still carries the bulk of real-time clinical messaging traffic.

• Best fit: Patient-facing and provider-facing apps, SMART on FHIR, third-party/analytics access, regulatory compliance for patient access.
• Key risk: Depends on vendor API readiness and maturity; request-response REST is not ideal for high-volume push or guaranteed asynchronous delivery.

Choosing and Mixing Patterns

Most mature environments run all four patterns simultaneously — a FHIR façade for external apps, an integration engine for HL7 v2 clinical feeds, Kafka for high-volume event distribution, and a handful of legacy point-to-point links that aren't worth re-plumbing. The architect's job is to place each workload on the right pattern. We recommend evaluating four dimensions:

• Throughput and latency: Low-volume, low-latency point links vs. high-volume fan-out that justifies a broker.
• Failure handling: Does the use case need guaranteed delivery, replay and durable buffering (broker/engine) or is best-effort request-response acceptable (REST)?
• Vendor API readiness: Can trading partners expose a conformant FHIR API, or are you limited to v2 feeds through an engine?
• Operational maturity: The team owning the integration layer must be able to run what you build — a Kafka cluster and an integration engine are ongoing operational capabilities, not one-time projects.

Where CaboLabs Fits

Designing the right blend of these patterns — and building the transformation, mapping and governance layers that make them work — is where most healthcare integration projects succeed or stall. CaboLabs has spent more than 20 years working exclusively in health information systems, standards and interoperability, with deep expertise across HL7 v2.x, FHIR, CDA, openEHR, DICOM, SNOMED CT and LOINC. We help organizations design interoperability architecture, select and implement integration engines, build FHIR and openEHR solutions, and turn fragmented point-to-point sprawl into a governable, standards-based platform.

If you are planning a new interoperability initiative, migrating off a legacy interface estate, choosing an integration engine, or designing a vendor-neutral clinical data platform, contact CaboLabs at cabolabs.com to talk with experts who work with your team, not just for it.