This page is part of the FHIR Specification v6.0.0-ballot1: Release 6 Ballot (1st Draft) (see Ballot Notes). The current version is 5.0.0. For a full list of available versions, see the Directory of published versions
FHIR Infrastructure Work Group | Maturity Level: N/A | Standards Status: Informative |
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.
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.
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.