Understanding FHIR Subscriptions Across Versions: R4, R4B, and R5

Over the years, the FHIR Subscription framework has undergone significant advancements, introducing better methods for systems to receive notifications about data changes. While these features haven't made their way into many production systems yet, the new guidance in R5 is promising for future adoption. In this post, we explore how FHIR Subscriptions differ across versions R4, R4B, and R5, and how the R5 Subscription Backport Implementation Guide helps bridge the gap for systems using earlier versions.

FHIR R4: The Foundation

In FHIR R4, subscriptions provide a simple mechanism for receiving notifications about changes to resources. The framework was built around the Subscription resource:

  1. Subscription Resource: Clients could register subscriptions using search criteria and specify notification channels such as REST hooks, email, or SMS.
  2. Limitations:
    • Lacked a structured topic model.
    • Offered limited filtering and minimal status tracking.

R4 laid the foundation but left room for improvement, particularly with regards to scalability and advanced filtering. It made significant improvements in support for rest-hooks.

FHIR R4B: Bridging the Gap

FHIR R4B introduced two key resources, SubscriptionTopic and SubscriptionStatus, signaling the transition toward a more modular, topic-based subscription framework:

  1. SubscriptionTopic:

    • Defines reusable events that trigger notifications.
    • Introduced the concept of multiple resource triggers and centralized event definitions.

  2. SubscriptionStatus:

    • Tracks subscription states in real time, adding transparency and error management.

While R4B brought these elements into draft status, they remained relatively basic. While there were some other changes in R4B that were incompatible with R4 Clinical Decision Support and Medications, most resources between R4 and R4B are compatible.

FHIR R5: Advancing the Framework

FHIR R5 fully realizes the potential of the subscription model by introducing significant enhancements:

  1. Enhanced Subscription Framework:

    • Aligns with modern “publish/subscribe” models.
    • Supports advanced use cases like batching and heartbeat notifications.

  2. Resource Updates:

    • SubscriptionTopic: Now a fully featured, modular framework for defining triggers.
    • SubscriptionStatus: Improved tracking and error handling.
    • Subscription: Standardizes proactive event notifications tied to defined topics.

  3. Standardized Notification Bundles:

    • Notifications are now delivered in a consistent Bundle format, supporting various payload types (empty, id-only, and full-resource).

The R5 Subscription Backport Implementation Guide

To enable earlier FHIR versions (R4 and R4B) to adopt these advancements, the R5 Subscription Backport Implementation Guide was introduced. This guide provides support for:

  • FHIR R4: Artifacts like operations and extensions to support topic-based subscriptions.

  • FHIR R4B: Supplemental components to bring SubscriptionTopic closer to R5 standards.

The Backport Guide ensures systems can leverage the improved scalability and flexibility of the R5 framework without requiring a full version upgrade.

Key Differences Across Versions

  1. Event Definition:

    • R4: Events are defined using search criteria in the Subscription resource.
    • R4B & R5: Events leverage the modular SubscriptionTopic resource.

  2. Notification Structure:

    • R5: Introduces notification bundles, providing a standardized format.

  3. Status Tracking:

    • R4B & R5: SubscriptionStatus resource enhances transparency and control.

  4. Filtering:

    • R5: Offers advanced filters with comparators and modifiers for refined criteria.

  5. Maturity:

    • R4B: Resources were in draft status (FHIR Maturity Model Level 0).
    • R5: Resources reached trial use (FHIR Maturity Model Level 2), offering robust security considerations.

What This Means for Developers

If you're building from scratch, using R4 is a good choice since it's the most predominant. However, if you want to add hooks, then using the R5 Backport implementation guide may be a good choice since it offers the most mature Subscription framework. It's important to consider what your jurisdiction requires in terms of FHIR version support and privacy requirements when choosing a version upon which to build.

If you're working on FHIR integrations or exploring how to improve your application’s data exchange capabilities, Topology Health can help you navigate the nuances of FHIR implementation.

Alex Goel

Co-Founder/CEO