The subscription resource is used describes a particular client's request to define be notified about a push-based subscription from 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 communicate with the 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 rules that filter properties to be applied to narrow the server should use subscription topic stream. When multiple filters are applied, evaluates to determine when true if all the conditions applicable to generate notifications 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 rules are search criteria (without filter as defined in the [base] part). Like Bundle.entry.request.url, it has no leading "/". SubscriptionTopic.canFilterBy.filterParameter element.

Comparator applied to this filter parameter.

A record of the last error that occurred when Must be a comparator allowed by the server processed 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 .

Details where An event filter to be applied to send notifications when resources are received that meet the criteria. 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 messages to. where notifications are sent.

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

The mime 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 send the payload channel for notifications, for example in - either application/fhir+xml, 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 the payload 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, then there a heartbeat notification is no payload not sent.

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

The mime MIME type "text/plain" to send the payload in - e.g., application/fhir+xml or application/fhir+json . Note that:

• clients may also 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 used for Email allowed by channels - e.g., text/plain and SMS subscriptions. text/html are defined by the Email channel.

How much resource content to deliver in the notification 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 .

Additional headers / information to send as part 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 notification. number of entries in a bundle, as dependent resources can be included.