Healthcare IT Glossary

What are FHIR Subscriptions?

Polling a FHIR API every minute to check whether anything changed has always been the wrong way to build real-time healthcare integrations. It wastes capacity on the server, introduces lag on the client, and produces noisy logs that make actual problems hard to find. The FHIR community has known this from the start, which is why Subscriptions have been part of the specification since DSTU2. What changed recently is that the standard finally grew up — R5’s Topic-based architecture made FHIR Subscriptions production-grade, and they’re now showing up as a default eventing mechanism in everything from clinical decision support to public health reporting.

Definition of FHIR Subscriptions How FHIR Subscriptions Work in Practice Common Use Cases Key Standards and Specifications Implementation Considerations How Taction Helps with FHIR Subscriptions

Definition of FHIR Subscriptions

FHIR Subscriptions are a standard mechanism for receiving real-time notifications when specified events happen on a FHIR server. A client expresses interest in particular changes — a new lab result, an admission, a medication order — and the server pushes a notification when those changes occur, instead of forcing the client to poll repeatedly.

The standard exists in two distinct generations, and the difference matters for anyone implementing today.

Legacy (DSTU2 / STU3 / R4) Subscriptions. The original model used the Subscription resource with a FHIR search criteria string as the filter. A client would create a Subscription with criteria like Observation?code=loinc-code-here&status=final, and the server would notify the client whenever a matching resource was created or updated. This worked, but it had real problems: search criteria expressiveness was inconsistent across servers, scaling to many subscribers was expensive, and notification payloads varied widely.

Topic-based Subscriptions (R5 and the R4 backport). R5 introduced SubscriptionTopic — a server-defined event specification that identifies what kind of event clients can subscribe to (encounter-start, lab-result-finalized, admit-discharge-transfer). Clients subscribe to topics rather than expressing arbitrary search criteria. The model is more constrained but vastly more scalable, predictable, and interoperable. The same architecture is available to R4 implementations through the Subscriptions R5 Backport Implementation Guide, which is what most production deployments target today.

Two key resources do the work in the topic-based model:

In simple terms: FHIR Subscriptions let healthcare systems push real-time event notifications instead of forcing clients to poll — and the modern Topic-based model is what makes the pattern scalable for production.

SubscriptionTopic. Defines the canonical event — what triggers it, what resources are involved, what the payload looks like. Server-published.

Subscription. A client-created resource that points to a SubscriptionTopic and specifies how the client wants to receive notifications (REST hook, WebSocket, email, message bus).

How FHIR Subscriptions Work in Practice

A working Subscription deployment moves through a predictable sequence.

Topic publication

The FHIR server publishes one or more SubscriptionTopic resources describing the events it can notify on. Each topic defines a canonical URL, the FHIR resources involved, the trigger conditions (created, updated, deleted), and any filters clients can apply when subscribing.

Subscription creation

A client POSTs a Subscription resource referencing the topic of interest. The Subscription specifies the channel (where notifications should be sent), the endpoint URL or address, the payload type, and any topic-specific filters.

Channel handshake

Most channels require some form of verification — for REST hooks, a one-time handshake notification confirms the receiver is willing and able to accept events. WebSocket channels open and authenticate a persistent connection.

Event detection

Whenever the FHIR server processes a transaction matching a topic’s trigger criteria — a new Observation with the right LOINC code, an Encounter transitioning to in-progress — the server identifies all active subscriptions interested in that event.

Notification dispatch

The server packages a Bundle containing notification metadata and (depending on the requested payload type) the resource itself. Three payload modes exist: empty (just an event count, the client polls for details), id-only (resource references), and full-resource (the resource itself).

Heartbeat and status

Long-running subscriptions exchange periodic heartbeat notifications so both sides know the channel is healthy. Subscriptions move through states (requested, active, error, off).

Error handling and recovery

When a notification fails — receiver unreachable, authentication expired, payload too large — the server records the failure and applies the configured retry policy. Clients implement their own catch-up logic for events missed during downtime.

Common Use Cases

Subscriptions show up across several real workflows in modern health IT.

Clinical decision support and alerting

A CDS service subscribes to events like new lab results, admission events, or medication orders, applies clinical logic, and surfaces alerts back into the EHR via SMART on FHIR launches or messaging.

Public health reporting

State health departments and CDC-supported networks subscribe to reportable events (immunizations, communicable disease lab results) so reports flow automatically rather than through batch extracts.

Care coordination

Care managers and post-acute providers subscribe to ADT events to know in real time when their patients move through the system.

Quality measure computation

Systems computing eCQM populations subscribe to relevant clinical events instead of running nightly extracts, which gives near-real-time measure performance feedback.

Population health and research

Research networks and registries subscribe to qualifying clinical events (matching cohort criteria, with appropriate consent) for ongoing case identification.

IoMT and device data flow

Connected medical device platforms subscribe to clinical events to correlate device data with clinical context.

Building an What are FHIR Subscriptions? integration? Let’s talk.

Book a free call

Key Standards and Specifications

Modern

FHIR R5 Subscriptions

The native modern specification, with SubscriptionTopic, the topic-based Subscription resource, and standardized notification Bundle structures.

Legacy

Subscriptions R5 Backport IG

The Implementation Guide that brings R5 Topic-based Subscriptions to R4 servers — the practical target for most US healthcare deployments, since FHIR R4 remains the regulatory baseline (USCDI, ONC certification, US Core).

Legacy

US Core Subscriptions

Profiles that constrain the backport IG for US clinical use cases — defining specific topics for common events (encounter notifications, lab result notifications) with the codings and value sets US implementations expect.

Legacy

HL7 Da Vinci PCDP

The Patient Cost and Data Payer implementation guide and related Da Vinci IGs use Subscriptions for payer/provider event flows.

Legacy

TEFCA and HL7 Argonaut

Both are pushing Subscription-based event delivery forward as part of nationwide exchange infrastructure.

Legacy

Channel Standards

Subscriptions delivery channels rely on existing standards: REST hook (HTTP POST notifications), WebSocket (persistent bidirectional connection), and emerging support for message-bus patterns (Kafka, AMQP) for high-throughput environments.

Legacy

Security

OAuth 2.0 and SMART on FHIR govern subscription creation. TLS protects the channel. Some implementations require mutual TLS or signed payloads for additional channel integrity. HIPAA applies throughout — notifications carrying PHI need the same protections as any other PHI flow.

Implementation Considerations

A few things separate Subscription deployments that work in production from ones that quietly fail.

Pick the backport IG, not the legacy criteria-based model

Even if your server is R4, target the R5 Backport IG. The legacy criteria-based model has too many cross-vendor inconsistencies to build durable integrations against.

Define topics carefully on the server side

A topic that’s too broad (“any Observation update”) generates a flood of irrelevant notifications. One that’s too narrow (“Observation with this exact LOINC code”) forces clients to subscribe to dozens of topics. Topic granularity is a design decision.

Plan for missed events

Subscriptions provide best-effort real-time delivery, not guaranteed delivery. Receivers go offline, networks fail, payloads time out. Every robust subscriber implements catch-up logic — usually a periodic FHIR query against the same criteria, used as a backstop against gaps.

Throttle and batch carefully

A burst of clinical activity (mass admission event, EHR data correction job) can produce thousands of notifications per second. Without rate limiting and smart batching, a subscriber gets overwhelmed and a notification dispatcher gets backed up.

Authentication on the receiver side

REST hook receivers are public endpoints by default. Without strong authentication on the receiving endpoint — token-based auth, mutual TLS, or signed payloads — an attacker who learns the URL can inject fake notifications.

Watch payload size and PHI exposure

Full-resource payloads are convenient but expose more PHI to whatever channel the notification traverses. For sensitive data, id-only mode plus a separately authenticated FHIR fetch is often the safer pattern.

Plan the subscription lifecycle

Subscriptions are state. They get created, modified, suspended, deleted. Stale subscriptions accumulate and consume server resources.

Test the failure modes

What happens when the receiver’s certificate expires? When the channel returns 500 errors? When the FHIR server itself is restarted mid-burst? These scenarios appear constantly in production.

Coordinate with the FHIR server vendor’s support

Subscription support varies meaningfully across server implementations. Some support the full R5 Backport IG. Some support legacy criteria-based only. Some support a partial subset with vendor-specific extensions. Confirm the support matrix before architecting around it.

How Taction Helps with FHIR Subscriptions

Subscriptions sit at the intersection of FHIR depth, eventing infrastructure, and integration discipline — three areas Taction has been building in for years. We work with health IT vendors and provider organizations on both sides of the Subscription model: building publishing infrastructure into FHIR servers, and building reliable subscriber implementations into downstream applications.

What we do:

If you’re designing a Subscription-based architecture, evaluating a FHIR server’s subscription capabilities, or working through specific implementation challenges, our healthcare integration team has the FHIR depth and eventing experience to help.

SubscriptionTopic design and publication

We design topic catalogs aligned with the R5 Backport IG and US Core profiles, balancing granularity, payload design, and trigger semantics for the specific clinical events the platform needs to support.

Subscriber implementations

We build robust subscriber clients for clinical applications, CDS engines, public health reporting platforms, and care coordination services — including the catch-up logic, retry handling, and idempotency discipline that production subscribers require.

Channel infrastructure

We design and implement the REST hook receivers, WebSocket gateways, and message-bus integrations (Kafka, AMQP) that serve as the delivery backbone for high-throughput Subscription deployments.

Mirth Connect to FHIR Subscription bridges

Our Mirth Connect consulting team builds the channels that translate HL7 v2 events into FHIR Subscription notifications, letting modern subscribers consume events that originate in legacy interface flows.

Authentication and PHI protection

We build the OAuth 2.0, mutual TLS, and signed-payload infrastructure that keeps subscription channels secure and HIPAA-aligned.

Operational tooling

Subscription management dashboards, monitoring, alerting, lifecycle automation — the operational layer that keeps a subscription deployment healthy after launch.

Explore Related Terms

Ready to discuss your What are FHIR Subscriptions? project?

Schedule a free call

What are FHIR Subscriptions?

Definition of FHIR Subscriptions

How FHIR Subscriptions Work in Practice

Common Use Cases

Key Standards and Specifications

Implementation Considerations

How Taction Helps with FHIR Subscriptions

Explore Related Terms

Ready to discuss your What are FHIR Subscriptions? project?

Ready to Discuss Your Project With Us?

What's Next?