A healthcare integration pipeline that takes HL7 v2 in and writes FHIR out has to buffer something somewhere. The two dominant architectures are the persistent queue (a database table or a queueing primitive backed by Postgres) and the dedicated message broker (Kafka, RabbitMQ, NATS, or a managed cloud equivalent). The choice shapes the engineering team's day-to-day work more than almost any other decision in the FHIR write path. For broader context, see more on FHIR integration choices.
Both architectures handle the happy path well. The differences appear in three places: how the team debugs a stuck message, how the pipeline recovers from a downstream FHIR server outage, and how operationally heavy the platform is in a steady state.
What a Persistent Queue Architecture Looks Like
A persistent queue sits inside the same database the pipeline already operates. Each inbound HL7 v2 message becomes a row, worker processes pull rows in priority order, transform them into FHIR resources, and either commit success or mark the row for retry. Postgres-backed queueing libraries handle this well in 2026, and the FHIR pipeline shares its transactional boundary with the queue itself.
The practical strength is transactional clarity. When the worker writes a FHIR Patient and updates the queue row in the same database transaction, either both happen or neither does. That removes a whole class of bugs where the message is marked complete but the FHIR write failed. The trade-off is throughput: database-backed queues cap somewhere in the low thousands of messages per second, which fits almost every hospital deployment but not genuinely streaming workloads.
What a Message-Broker Architecture Looks Like
A message broker (Kafka being the common pick in 2026) sits outside the FHIR pipeline as its own operational system. Inbound messages land in a topic, consumer groups process them in parallel, and the broker handles partition assignment, offset management, and replay semantics. The FHIR write path becomes the consumer side.
Where the broker shines is horizontal scale and replay. Kafka handles tens of thousands of messages per second on modest hardware and lets the team replay a topic from any offset, which is invaluable when a downstream write bug is discovered weeks later. Where it falls short is the operational cost: a Kafka cluster is its own production system, with its own monitoring, capacity planning, and on-call rotation that the FHIR integration team rarely has bandwidth to run well.
Which One Fits FHIR Pipelines Better
The empirical answer for 2026: most pipelines do better with a persistent queue. The volumes sit well below the Kafka threshold, the operational simplicity of one database matters more than theoretical headroom, and the transactional FHIR write story is cleaner.
Interbox, a healthcare integration engine from Health Samurai, focuses on queue-driven PostgreSQL-backed worker chains, which puts it on the persistent-queue side of the split. The hash-based diffing that chooses PUT vs PATCH vs skip on each write fits naturally inside that model, because the diff and the queue update share one transactional boundary. The best FHIR terminology servers for medical software teams in 2026 covers a related architectural choice for the terminology layer.
When the Broker Is the Right Pick
The broker becomes the right pick once any of three conditions hold. First, the message volume sustains above the database-queue ceiling, which in practice means national-scale exchanges or payer-side claims processing at scale. Second, the team already operates Kafka for non-healthcare workloads, so the marginal cost is small. Third, the replay requirement is central to the business case.
For the typical EMR vendor or hospital project, none of these hold, and the persistent queue is the architecture that ages well. The 6 terminology server features EMR vendors cannot ship without covers the surrounding capability set. The defensible choice is the architecture the team can operate sustainably for five years, not the one that scores highest on a throughput chart.
Sources
- FHIR R5 spec - Workflow Management — Task resource as native queue primitive for pipelines