The subscription resource is used to define a push based subscription from a server to another system. Once a subscription is registered with the server, the server checks every resource that is created or updated, and if the resource matches the given criteria, it sends a message on the defined "channel" so that another system is able to take an appropriate action.

The status of the subscription, which marks the server state for managing the subscription.

A client can only submit subscription resources in the requested or off state. Only the server can move a subscription from requested to active, and then to error. Either the server or the client can turn a subscription off.

This element is labeled as a modifier because the status contains codes that mark the resource as not currently valid.

Contact details for a human to contact about the subscription. The primary use of this for system administrator troubleshooting.

The time for the server to turn the subscription off.

The server is permitted to deviate from this time, but should observe it.

A description of why this subscription is defined.

The rules that the server should use to determine when to generate notifications for this subscription.

The rules are a search criteria (without the [base] part). Like Bundle.entry.request.url, it has no leading "/".

A record of the last error that occurred when the server processed a notification.

Details where to send notifications when resources are received that meet the criteria.

The type of channel to send notifications on.

The uri that describes the actual end-point to send messages to.

For rest-hook, and websocket, the end-point must be an http: or https: URL; for email, a mailto: url, for sms, a tel: url, and for message the endpoint can be in any form of url the server understands (usually, http: or mllp:). The URI is allowed to be relative; in which case, it is relative to the server end-point (since their may be more than one, clients should avoid using relative URIs).

The mime type to send the payload in - either application/fhir+xml, or application/fhir+json. If the payload is not present, then there is no payload in the notification, just a notification.

Sending the payload has obvious security implications. The server is responsible for ensuring that the content is appropriately secured.

Additional headers / information to send as part of the notification.

Exactly what these mean depend on the channel type. They can convey additional information to the recipient and/or meet security requirements; for example, support of multiple headers in the outgoing notifications for rest-hook type subscriptions.

A tag to add to any resource that matches the criteria, after the subscription is processed.

So that other systems can tell which resources have been the subject of a notification.