The subscription resource is used to define a push-based subscription from describes a server particular client's request to another system. Once a subscription is registered with the server, the server checks every resource that is created or updated, and if the resource matches the given criteria, it sends be notified about a message on the defined "channel" so that another system can take an appropriate action. 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 the subscription is authorized to disclose.

A description of why this subscription is defined.

The rules 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 determine when 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.

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

A record of the last error that occurred when the server processed a notification. Modifier applied to this filter parameter.

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

Details where to send notifications when resources are received that meet the criteria. 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 notifications to.

For rest-hook, and websocket, rest-hook the end-point must be an http: or https: URL; for websockets, ws: or wss: ; for email, a mailto: url, for sms, a tel: url, url; and for message the endpoint can be in any form of url the server understands (usually, http: http/s : or mllp:). 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).

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

Exactly what these mean depend 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 - either application/fhir+xml, 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 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 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.

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.