Subscriptions R5 Backport
0.1.0 - ballot

Subscriptions R5 Backport, published by HL7 FHIR Infrastructure WG. This is not an authorized publication; it is the continuous build for version 0.1.0). This version is based on the current content of and changes regularly. See the Directory of published versions


What are Subscriptions?

The Subscriptions Framework is a mechanism designed to allow clients to ask for notifications when data changes. It is an active notification system; a FHIR server actively sends notifications to clients as changes occur.

Subscriptions in R4

There is a defined Subscription resource in FHIR R4, which has been in place since DSTU2. In those releases of FHIR, subscriptions are defined by a client at run-time via a query. The FHIR server must then run the query and track the query result-set for each subscription request. Each time a change to the server’s data is made, a server must re-run the query and send notifications to clients if their result-set changes (e.g., a new entry is added or removed).

The above approach works well for some use cases, but has issues which prevent it from being used in others. Some of the issues identified include:

  • Difficulty implementing the server-side logic at scale (both in terms of large datasets and many clients).
  • An opaque discovery process (e.g., servers that had restrictions on queries had no way to advertise them).
  • Lack of granularity in events (e.g., it was unclear why something was removed from a dataset).
  • No ability to bundle notifications (e.g., servers had to send a single notification for each discrete event).
  • Notifications required clients to re-query after receiving a notification.

While some of the issues would be addressable with modifications to the existing Subscription resource, the FHIR Infrastructure Work Group felt that more extensive changes were needed, and so started a redesign of Subscriptions for R5.

Subscriptions in R5

More than a year of focused work resulted in a new design for Subscriptions in FHIR R5. The redesign focused on three main areas:

  1. Moving to a topic-based model, with the defintion of a SubscriptionTopic resource.
  2. Changing the Subscription resource to add clarity and flexibility.
  3. Restructuring notifications by adding a new Bundle type.

The implementer response to these changes has been overwhelmingly positive - changes to the mechanism address the issues identified and retain all of the existing functionality. However, many implementers are concerned that both publication and adoption of FHIR R5 are both in the future.

Boundaries and Relationships

Relation to FHIRcast

FHIRcast is a framework for user-activity synchronization across applications. FHIRcast and Subscription are both conceptually based W3 WebSub, and while the mechanics of two projects look similar, they are fundamentally different projects used to address different use cases. In particular:

  1. What Is Communicated
    • FHIRcast is primarily concerned with context syncrhonization.
    • Subscriptions are focused on content synchonization.
  2. User Interaction
    • FHIRcast is designed to be used by multiple applications perhaps with the same user and typically on the same device.
    • Subscriptions are designed to be used by multiple distinct systems, often outside of a user workflow.
  3. Session Duration
    • FHIRcast is designed around short-lived sessions.
    • Subscriptions are intented to be long-lived resources.
  4. Event Frequency
    • FHIRcast sends only single-event notifications.
    • Subscriptions allow servers to batch multiple notifications in high-frequency scenarios.

Relation to FHIR Messaging

FHIR Messaging is a message-based protocol which can be used for communication. When combining Messaging and Subscriptions, complete notifications are wrapped into Messaging Bundles. More details are provided on the channels page.

This IG

In response to requests for a way to use “R5-style” subscriptions in earlier versions of FHIR, this Implementation Guide has been authored. The goal is to provide a standard set of artifacts and extensions so that consistent behavior can be achieved prior to the release and adoption of FHIR R5.