Share via

Subscription Support in Azure FHIR R4

Rajat Singhal 25 Reputation points
2026-03-17T05:08:25.3033333+00:00

I am working on CMS 0057F compliance and focused towards PAS Compliance which mandates subscriptions (Implementers SHALL support the R4 Subscriptions referenced in the Subscriptions for R5 Backport Implementation Guide.) I am unable to have it working on azure fhir service R4 since it does not trigger webhooks calls even after creating subscriptions.

Azure is also not supporting FHIR operatiosn which are provided by Backport R5 subcriptions IG.
In order to meet compliance we need this to be supported by FHIR service R4.

Please suggest

Azure Health Data Services
Azure Health Data Services

An Azure offering that provides a suite of purpose-built technologies for protected health information in the cloud.


Answer accepted by question author
  1. Rakesh Mishra 7,295 Reputation points Microsoft External Staff Moderator
    2026-03-17T11:21:21.02+00:00

    Hello Rajat,

    You have encountered a known limitation within the managed Azure Health Data Services API for FHIR. Your observation is completely correct: the managed Azure FHIR service natively supports FHIR R4 but does not currently implement native webhook triggering for the Subscription resource, nor does it natively support the operations required by the R5 Backport Subscriptions Implementation Guide (IG).

    Because the managed FHIR service is a turn-key Platform-as-a-Service (PaaS), its feature surface is strictly limited to officially documented capabilities. To achieve CMS-0057F PAS (Prior Authorization Support) compliance on Azure, you will need to implement an architectural workaround or use the open-source alternative.

    Here are the two primary pathways to solve this and meet your compliance mandates:

    Option 1: The Azure-Native Workaround (Event Grid + Azure Functions)

    While the managed service doesn't trigger webhooks natively via FHIR Subscriptions, it does support near-real-time notifications through Azure Health Data Services Events. You can build a "Subscription Processor" outside of the FHIR server using Azure's event-driven architecture.

    How it works:

    1. Enable Events: Configure your Azure Health Data Services workspace to emit events (e.g., FhirResourceCreated, FhirResourceUpdated) to an Azure Event Grid topic.
    2. Event Routing: Route these events to an Azure Service Bus queue or directly to an Azure Function App.
    3. The Subscription Processor (Function App): The Function App acts as your custom subscription engine. When an event arrives, the Function queries the FHIR server (if necessary), evaluates the resource against your defined Subscription criteria (acting as the R5 Backport interpreter), and executes the outgoing HTTP REST-hook/webhook call to the PAS system.

    Note on Accelerators: Microsoft Cloud Solution Architects and the community have built open-source tools to jumpstart this exact pattern. For example, you can look into GitHub repositories like FHIRSubscriptionProcessor (an Azure Function App solution that listens to Event Grid, evaluates R4 Subscriptions, supports rest-hook callbacks, and even includes parameters for R5 backport features).

    Option 2: Use the Open-Source FHIR Server for Azure

    If the PAS compliance mandate requires the FHIR server to natively accept specific R5 Backport extended operations (e.g., custom $events or $topic-match operations) that cannot simply be emulated with an external Function App, the managed service will block you.

    In this scenario, you should migrate to the Open-Source FHIR Server for Azure (Microsoft's open-source repository backing the managed service).

    • Why? By hosting the OSS version yourself (e.g., via Azure App Service or AKS), you gain full control over the C# codebase.
    • You can extend the pipeline, write custom interceptors for the R5 Backport IG operations, and build native webhook trigger mechanisms directly into the server's core execution flow.
    Recommendation for CMS-0057F Compliance

    If you prefer to stay on the managed PaaS offering for its compliance and maintenance benefits, Option 1 is the heavily favored path. Many organizations facing CMS interoperability mandates build a facade/processor layer using Azure Functions and API Management in front of the Azure FHIR service to handle complex, IG-specific routing and webhook criteria that the base server does not natively support. Note: This response is drafted with the help of AI systems.

    0 comments No comments

2 additional answers

Sort by: Most helpful
  1. Rajat Singhal 25 Reputation points
    2026-03-17T05:30:50.5933333+00:00

    I need help from community support to help solve the issue.

    0 comments No comments

  2. Q&A Assist
    2026-03-17T05:08:58.4733333+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    FHIR service in Azure Health Data Services provides a managed implementation of the open-source FHIR Server and supports FHIR R4 (4.0.1) and STU3 (3.0.2), along with a defined set of REST and extended operations. The documented extended operations and capabilities for the service do not include the R5 Backport Subscriptions IG features or additional subscription-related FHIR operations beyond what is natively in the server.

    From the available feature list, the only extended operations supported are:

    • $export
    • $convert-data
    • $validate
    • $member-match
    • $patient-everything
    • $purge-history
    • $import
    • $bulk-delete

    No additional R5 Backport Subscriptions IG–specific operations are listed, and there is no documentation indicating that the R4 FHIR service currently implements the R5 Backport Subscriptions behavior or guarantees webhook triggering semantics required for CMS-0057F PAS compliance.

    Given this, the FHIR service R4 as documented cannot be configured to provide the full R5 Backport Subscriptions IG feature set required for PAS compliance. To meet those requirements, options are limited to:

    • Implementing the needed subscription behavior and operations on the open-source FHIR Server for Azure (which can be extended and customized), and hosting that instead of or alongside the managed FHIR service.
    • Monitoring the official FHIR service feature documentation for future updates that might add support for the required subscription capabilities.

    The managed FHIR service is designed as a turn-key, production-ready FHIR API where access is through the FHIR API only and feature surface is limited to what is documented; for scenarios that require extending or customizing the server (such as implementing additional subscription semantics or IG-specific operations), the open-source FHIR Server for Azure is the recommended path.


    References:

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.