Subscriptions allow a data source to notify interested data consumers when a specific event occurs. This might be the creation of a record or the update of a record to match a specific set of criteria. Using Subscription requires that the data source has the infrastructure to support consumer subscribing and can detect events as they occur and send out notifications. However, it is significantly less resource-intensive overall than polling.

Subscription can have two slightly different business flows. In both cases the data consumer POSTs (or updates) a Subscription instance on the data source indicating the type(s) of data it wants to receive. At some point, an event happens within the data source that falls within the criteria set by the subscription. At that point, the subscription will either pass the data directly or it will simply send a notification.

Subscription notifications with data

This approach is the simplest workflow because the data flows to the data consumer immediately, however it requires that the notification process be appropriately secure - and it means that any security rules governing permissions, consent or other access restrictions must be able to apply not only in the context of queries, but also in the context of the subscription mechanism - which may be in a completely different portion of the application.

Subscription notifications with query

In this mode, the initial notification simply indicates that 'data is available' or possibly the record ids of the relevant records. It does not expose the data itself. Because the shared information does not expose any healthcare or personally identifying information, the security expectations for the notifications are lower. The data source can subsequently query to retrieve the data at its convenience and all the data source's typical mechanism for authorizing the user, performing audit, ensuring permissions and consent, etc. can take place as they would for any query.