---
type: "doc"
source: "source/exchanging-subscription.html"
---
\[%settitle Exchanging with FHIR Subscription%\] \[%file newheader%\] \[%file newnavbar%\]

## Exchanging with FHIR Subscription

| Responsible Owner: [\[%wgt fhir%\]]([%wg fhir%]) Work Group | [Standards Status](versions#std-process):[Informative](versions#std-process) |
| --- | --- |

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](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](exchanging-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](#push) or it will [simply send a notification](#pull).

### 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.

\[%file subscription-push.svg %\]

### 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.

\[%file subscription-pull.svg %\]

\[%file newfooter%\]