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

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 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 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 Topic.canFilterBy.name 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".

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

Recommended practice: If available, convey the HTTP error in an adjacent Coding or in text.

A record of the number of events for which the server has attempted delivery on this subscription (i.e., the number of events that occurred while the subscription is in an "active" or "error" state -- not "requested" or "off"). Server Initializes to 0 for a new subscription. Repeated attempts at delivery of the same event notification do not increment this counter. Valid values are unsigned integers (0+). The decmial type is used to ensure that counts can grow larger than 32-bit values.

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

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.

The payload mimetype and content. If the payload is not present, then there is no payload in the notification, just a notification.

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.