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, 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 filter as defined in the SubscriptionTopic.canFilterBy.filterParameter element.

The rules are Comparator applied to this filter parameter.

Must be a search criteria (without comparator allowed by the [base] part). Like Bundle.entry.request.url, it has no leading "/". SubscriptionTopic relevant to this Subscription filter.

Modifier applied to this filter parameter.

A record of the last error that occurred when the server processed Must be a notification. 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 uri 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 their there may be more than one, clients should avoid using relative URIs).

The mime type Channel-dependent information to send as part of the payload in - either application/fhir+xml, notification (e.g., HTTP Headers).

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

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

Sending Parameter value for information passed to the payload has obvious security implications. The server is responsible channel for ensuring that notifications, for example in the content is appropriately secured. case of a REST hook wanting to pass through an authorization header, the value would be Bearer 0193... .

Additional headers / information 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 notification. maximum amount of time a server will allow before failing a notification attempt.

Exactly what these mean depend on the channel type. They can convey additional information The MIME type to send the recipient and/or meet security requirements; for example, support of multiple headers payload in the outgoing - e.g., application/fhir+xml or application/fhir+json . Note that:

• clients may request notifications for rest-hook type subscriptions. 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.

A tag to add to any How much resource that matches content to deliver in the criteria, after notification payloads. The choices are an empty payload, only the subscription is processed. 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 .

So If present, the maximum number of events that other systems can tell which resources have been will be included in a notification bundle. Note that this is not a strict limit on the subject number of entries in a notification. bundle, as dependent resources can be included.