Subscriptions in FHIR — the great unhandled resource!

Chances are you’re not using the Subscription resource in FHIR. When implemented, it can be one of the most useful of all FHIR resources.

The purpose of the Subscription resource is to define a set of criteria that triggers a notification event whenever a resource that meets the criteria is created or updated.

This notification can be a call to a web hook endpoint, a message sent to a web socket, or an email sent to an email address.

Here’s a sample use case:

The FHIR server of a large chain of hospitals has a problem with duplicate Patient resources entering the system. The checks to prevent duplicates are not robust enough.

A FHIR Subscription resource is created to notify an external application whenever a new Patient is added. The application then runs a series of checks to identify whether or not the Patient already exists in the system.

This may take the form of fuzzy name matching, address and contact details matching, identifier (SSN or driver’s license) matching.

If a duplicate or possible duplicate is detected, the new Patient resource is flagged for further investigation.

The criteria in the Subscription resource can be loosely or tightly defined and can avail itself of the full array of search parameters. Example:


Triggers whenever a Patient with a US social security number identifier is created or updated.

Subscriptions are incredibly useful. But very few FHIR servers implement them, and when they do that implementation is often limited.

More about Subscriptions:

It’s worth mentioning that the Subscription resource and associated resources have been improved a lot in FHIR versions R4b and R5, though the problem of so few FHIR servers implementing them remains.



Sign up to “The Tuesday FHIR Sessions” and receive an email every Tuesday where I go deep on a single FHIR topic.