What are 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:

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.

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.

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:

Explore related glossary terms: