FHIR Subscriptions vs Polling: Which Wins for Clinical Event Streams

A clinical event stream can be delivered two ways: push, via FHIR Subscriptions, or pull, via consumer-side polling of `_lastUpdated` searches. The two patterns ship with different operational costs and different failure modes, and the choice is rarely as obvious as the spec discussions imply. The comparison below covers what each looks like in 2026 production deployments. For broader context, see the FHIR comparison hub.

What Subscriptions Cost and Cover

Subscription R5 with Subscription Topics is the spec-aligned push path. The server tracks consumer endpoints, evaluates topic filters on each resource change, and pushes notifications without waiting for the consumer to ask. The wins are obvious: low latency, no wasted polling cycles, and a clean ordered stream when the engine implements it well.

The hidden costs are real. The server now owns durability for in-flight notifications. At-least-once delivery is not part of the base spec, so server implementations vary in how they handle a consumer that disconnects mid-stream. Replay is similarly implementation-specific. And the server now scales with the cross-product of (writes) and (matching subscriptions), which can dominate the load profile of a busy FHIR API.

The FHIR Subscription engines roundup covers which engines handle durability and replay well and which leave the work to the consumer.

What Polling Cost and Cover

Polling on `_lastUpdated` is the pull path. The consumer queries the FHIR API at a chosen interval, requests resources changed since the last successful checkpoint, and processes them locally. The wins are operational simplicity and easy recovery: a consumer that crashes resumes from its last checkpoint without coordinating with the server.

The hidden costs are also real. Polling adds steady load proportional to the consumer count and the polling frequency, not to the actual event rate. Tight polling intervals approach Subscription latency but at higher server cost; loose intervals reduce load but lose the freshness that motivated the integration. And polling can miss events that arrive and depart inside a polling window if the resource version semantics are not handled carefully.

Which One Wins for Which Workload

Three workload shapes pick the pattern almost automatically. Acute pathways with hard latency budgets win on Subscriptions, assuming the engine is one of the durable implementations rather than the bare-bones reference path. The acute care workflow tools roundup covers the engines that hold up here.

Batch-style downstream processing wins on polling. Analytics jobs, claims feeds, and population health enrichment do not need sub-second freshness and benefit from the simpler recovery model. The lost latency is not a real cost; the gained operational simplicity is.

Mixed workloads, where the same FHIR API feeds both acute alerts and batch analytics, usually run both patterns side by side. Subscriptions drive the latency-sensitive consumers; polling serves the rest. The pattern overlap is well-tolerated by modern FHIR engines and is the most common topology in 2026 production deployments. The closely related EHR notification tools roundup covers the consumer-side patterns that pair with each.

The right answer depends on the consumer's latency budget, the team's appetite for managing Subscription durability, and the load profile the FHIR API has to absorb. Most production stacks end up running both. Picking one pattern as the global answer usually leads to the other one being grafted on awkwardly later when a new consumer arrives with different latency or simplicity requirements.