The subscription resource describes a particular client's request to be notified about a SubscriptionTopic.

A formal identifier that is used to identify this code system when it is represented in other formats, or referenced in a specification, model, design or an instance.

A natural language name identifying the subscription.

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.

The reference to the subscription topic to be notified about.

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 filter properties to be applied to narrow the subscription topic stream. When multiple filters are applied, evaluates to true if all the conditions are met; otherwise it returns false. (i.e., logical AND).

The filter label (=key) as defined in the SubscriptionTopic.canfilterBy.searchParamName element.

The operator to apply to the filter value when determining matches (Search modifiers).

The literal value or resource path as is legal in search - for example, "Patient/123" or "le1950".

The type of channel to send notifications on.

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

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

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.

If present, a 'hearbeat" notification (keepalive) is sent via this channel with an the interval period equal to this elements integer value in seconds. If not present, a heartbeat notification is not sent.

If present, the maximum amount of time a server will allow before failing a notification attempt.

The mime type to send the payload in - either application/fhir+xml, or application/fhir+json. The MIME types "text/plain" and "text/html" may also be used for Email subscriptions.

How much of the resource content to deliver in the notification payload. The choices are an empty payload, only the resource id, or the full resource content.

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