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.

Entity with authorization to make subsequent revisions to the Subscription and also determines what data communicate with the subscription is authorized to disclose. server about this Subscription, such as requesting changes (e.g., updating an endpoint URL).

Note that the managing entity for a subscription does not need to be the client (e.g., in the case of server-managed Subscriptions).

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 applicable to that resource are met; otherwise it returns false (i.e., logical AND).

A resource listed in the SubscriptionTopic this Subscription references ( SubscriptionTopic.canFilterBy.resource ). This element can be used to differentiate filters for topics that include more than one resource type.

The filter as defined in the SubscriptionTopic.canFilterBy.filterParameter element.

Comparator applied to this filter parameter.

Must be a comparator allowed by the SubscriptionTopic relevant to this Subscription filter.

Modifier applied to this filter parameter.

Must be a modifier allowed by the SubscriptionTopic relevant to this Subscription filter.

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

An event filter to be applied to the topic - e.g., if a topic defined multiple event triggers, this can be used to specify a single one. Multiple values are or-joined, multiple codings within a value are and-joined.

The type of channel to send notifications on.

The url Channel-specific URL that describes the actual end-point to send where notifications to. are sent.

The URL requirements are based on channel type. For example, in a rest-hook channel, the end-point URL must be an http: or https: URL; for websockets, use the ws: http or wss: https ; for email, protocol and be supplied by the client; in a mailto: websocket url; and for message channel, the endpoint can be in any form of url URL uses the server understands (usually, http/s : ws or mllp: wss ). The protocol and is supplied by the server.

Note that the URI is allowed to be relative; in which case, it is relative. Relative URLs are relative to the FHIR server end-point base URL (since there may be more than one, clients should avoid using relative URIs).

Channel-dependent information to send as part of the notification (e.g., HTTP Headers).

Exactly what these mean depends on the channel type. They can convey additional information to the server or recipient and/or meet security requirements; for example, support of multiple headers in the outgoing notifications for rest-hook type subscriptions. Note that names are not required to be unique, but channel definitions can impose restrictions.

Parameter name for information passed to the channel for notifications, for example in the case of a REST hook wanting to pass through an authorization header, the name would be Authorization.

Parameter value for information passed to the channel for notifications, for example in the case of a REST hook wanting to pass through an authorization header, the value would be Bearer 0193... .

If present, a 'heartbeat' notification (keep-alive) is sent via this channel with an 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 - e.g., application/fhir+xml or application/fhir+json . Note that:

• clients may request notifications in a specific FHIR version by using the FHIR Version Parameter - e.g., application/fhir+json; fhirVersion=4.0 .

• additional MIME types can be allowed by channels - e.g., text/plain and text/html are defined by the Email channel.

How much of the resource content to deliver in the notification payload. payloads. 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. For additional information, see Notification Content .

If present, the maximum number of events that will be included in a notification bundle. Note that this is not a strict limit on the number of entries in a bundle, as dependent resources can be included.