Enterprise Service Bus (ESB)

The engine that directs messages to their correct destinations based on content, type, or rules. Unlike brittle point-to-point interfaces, an ESB uses a hub-and-spoke model to decouple senders from receivers.

• Content-Based Routing: Inspects message payload (e.g., MSH-9 trigger event in HL7 v2) to determine the target system.
• Publish/Subscribe: Delivers a single message to multiple interested subscribers via a topic.
• Itinerary-Based Routing: Defines a sequential path for a message to flow through multiple services for orchestration.

Converts data between disparate formats to ensure semantic equivalence. The ESB acts as a universal translator, often normalizing data into a canonical data model to reduce the number of required point-to-point mappings.

• Format Conversion: Transmutes HL7 v2 pipe-and-hat syntax into FHIR JSON resources or C-CDA XML documents.
• Protocol Bridging: Accepts a TCP/IP MLLP connection and forwards the payload over a SOAP web service or REST API.
• Content Enrichment: Augments a message with data from a reference database (e.g., appending a patient's insurance details from an Enterprise Master Patient Index).

Coordinates multiple fine-grained services into a single, composite business process. The ESB executes a defined flow, handling conditional logic and sequential invocations.

• Process Choreography: Manages long-running, stateful workflows like a full prior authorization automation submission, coordinating eligibility checks, clinical data extraction, and payer response handling.
• Scatter-Gather: Broadcasts a request to multiple providers (e.g., three different drug formulary services) and aggregates the responses into a single reply.
• Compensation Handling: Defines and executes rollback logic if a step in a multi-service transaction fails.

Ensures zero message loss through persistent storage and acknowledgment protocols, a critical requirement for patient safety in clinical workflows.

• Store-and-Forward: Persists the message to disk before attempting delivery to the target system.
• Transactional Integrity: Wraps message consumption and processing in an atomic unit of work; a failure rolls back the read.
• Dead Letter Queue: Automatically routes messages that fail after all retry attempts to a specialized queue for manual administrative inspection and resolution.

Provides a uniform connectivity layer that hides the complexity of diverse transport mechanisms from application developers. The ESB handles the low-level handshakes.

• Inbound Adapters: Listen for connections via MLLP (common for HL7 v2), SOAP, JMS, AMQP, or SFTP.
• Outbound Adapters: Actively connect to and post messages to target systems using their native protocol.
• Authentication Mediation: Manages disparate security tokens, converting a basic OAuth 2.0 bearer token from a SMART on FHIR app into a SAML assertion required by a legacy service.

Provides centralized operational visibility into the health of all integration flows, enabling proactive detection of bottlenecks and failures.

• Message Tracking: End-to-end auditing of every message's path through the bus, establishing data provenance for compliance.
• SLA Alerting: Triggers notifications when a specific queue depth exceeds a threshold or message processing latency violates a defined service-level agreement.
• Centralized Logging: Aggregates errors and transaction logs from all deployed integration artifacts into a single console for root cause analysis.

A design pattern that defines a single, application-independent data format to which all incoming messages are translated before routing. This approach:

• Drastically reduces the number of required field-level mappings
• Decouples source and target system schemas
• Enables a single transformation per endpoint rather than pairwise mappings

For example, an ESB might define a canonical Patient Admission object that HL7 v2 ADT messages, FHIR Encounter resources, and proprietary EHR APIs all map to before downstream processing.

The runtime process of converting messages between formats, protocols, and semantic representations. An ESB performs:

• Syntactic transformation: Converting HL7 v2 pipe-delimited messages to FHIR JSON resources
• Semantic transformation: Mapping local codes like 'M' to SNOMED CT 248153007 for gender
• Protocol bridging: Accepting a TCP/IP MLLP feed and delivering via RESTful HTTPS

This capability is essential when integrating legacy ADT feeds with modern SMART on FHIR applications.

A message queuing mechanism that ensures no clinical message is lost in transit by persisting it to durable storage until the receiving system acknowledges successful consumption. Key characteristics:

• Store-and-forward architecture with persistent queues
• Automatic retry with exponential backoff on delivery failure
• Messages that exhaust retries are routed to a Dead Letter Queue for manual intervention

This pattern is critical for patient safety in workflows like lab result delivery, where a lost critical value could delay life-saving treatment.

The intelligent coordination layer where an ESB composes multiple fine-grained services into a single business process. Unlike simple routing, orchestration:

• Maintains process state across multiple service invocations
• Handles compensation logic when a step in the chain fails
• Implements long-running transactions with human workflow steps

A prior authorization orchestration might call a patient eligibility service, a clinical data extraction service, and a payer submission endpoint in sequence, with conditional branching based on each response.