• Content
• Examples
• Detailed Descriptions
• Mappings
• Profiles & Extensions
• Operations
• R3 R4 Conversions
• Search Params

2.46 2.13 Resource Subscription - Content

FHIR Infrastructure Work Group

Maturity Level : 3 2

Trial Use

Security Category : Business

Compartments : Not linked to any defined compartments

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.

2.46.3 2.13.3 References to this Resource

This resource is referenced by

• Resource References: SubscriptionStatus . This resource does not implement any patterns.

2.46.4 2.13.4 Resource Content

 

See the Profiles & Extensions and the alternate Additional definitions: Master Definition XML + JSON , XML Schema / Schematron + JSON Schema , ShEx (for Turtle ) + see the extensions , the spreadsheet version & the dependency analysis

2.46.4.1 2.13.4.1 Terminology Bindings

Subscription.channel.type Subscription.channel.payload

Path	Definition	Type	Reference
Subscription.status	State values for FHIR Subscriptions.	Required	SubscriptionStatusCodes (a valid code from SubscriptionStatus )
Subscription.filterBy.resourceType	All FHIR types	Extensible	FHIRTypes (a valid code from All FHIR Types )
Subscription.filterBy.modifier	FHIR search modifiers allowed for use in Subscriptions and SubscriptionTopics.	Required	SubscriptionSearchModifier (a valid code from SubscriptionSearchModifer )
Subscription.channelType	Core-defined FHIR channel types allowed for use in Subscriptions.	Extensible	SubscriptionChannelType (a valid code from SubscriptionChannel Type Codes )
Subscription.contentType	This value set includes all possible codes from BCP-13 (http://tools.ietf.org/html/bcp13)	Required	Mime Types MimeTypes (a valid code from urn:ietf:bcp:13 )
Subscription.content	Codes to represent how much resource content to send in the notification payload.	Required	SubscriptionPayloadContent

2.46.5 2.13.5 Safety and Security

Executing each of Applications are responsible for following FHIR security guidance . Some recommendations specific to subscriptions are provided on the channels documented below involves Subscriptions Framework page.

2.13.6 Payload Types

There are three options available when specifying the server sending contents of a communication that will reveal information about Notification: empty , id-only , and full-resource . These options change the client level of detail conveyed in the notification Bundle .

When deciding which payload type to request, systems SHOULD consider both ease of processing and server relationship, and, if security of PHI. To mitigate the entire resource is sent, administrative or clinical risk of information that may be quite sensitive and/or protected under law. Servers are responsible for ensuring appropriate leakage, systems SHOULD use the minimum level of detail consistent with the use case. In practice, id-only provides a good balance between security is employed and performance for each channel. The subscription resource does not address these concerns directly - it is assumed that these are administered by other configuration processes. For instance, many real-world scenarios.

If a server might maintain cannot or will not honor a whitelist of acceptable servers for payload type (e.g., will not send full-resource over HTTP), it SHOULD reject the rest-create/rest-update methods. Subscription request. A server MAY instead accept the subscription with modifications and return the accepted version to the client.

Emails should generally be secured using some technique such as Direct . When sending event notifications servers SHALL populate the SubscriptionStatus.notificationEvent structure with relevant information, depending on the payload type.

2.46.6 2.13.6.1 Managing Subscriptions and Errors empty

A subscription is defined by creating An example notification with an empty payload can be found here .

With the Subscription resource on content type of empty , all information about the server. When resources involved in triggering the subscription notification is created only available via channels other than the Subscription itself (e.g., the REST API or $events operation). This mitigates many security concerns by both removing most PHI from the client, notification and allows servers to consolidate authorization and authentication logic. When the subscriber receives a notification of this type, it sets may query the status server to "requested". After POSTing fetch all the subscription, relevant resources based on the SubscriptionTopic and applicable filters. The client parses might include a _lastUpdated query parameter, supplying its last query timestamp to retrieve only the Location header and saves most recent resources. For example, if the new Subscription's logical id notification is for use in subsequent operations. a topic about patient admission, the subscriber will generally query for recent Encounters for a patient or group of patients, then fetch them as needed.

When populating the server receives a subscription, it SHOULD check that it is prepared to accept/process the subscription. If it is, it sets the subscription to active , and then process it like SubscriptionStatus.notificationEvent structure for a normal create . If it isn't, it SHOULD return an error notification with an OperationOutcome instead of processing the create . empty payload, a server SHALL NOT include references to resources (e.g., SubscriptionStatus.notificationEvent.focus and SubscriptionStatus.notificationEvent.additionalContext SHALL NOT be present).

The criteria are subject to the same limitations as When the client that created it, such as access to patient compartments etc. Note that content type is empty , notification bundles SHALL NOT contain Bundle.entry elements other than the subscription remains active after SubscriptionStatus for the client access tokens expire. notification.

2.13.6.2 id-only

Once An example notification with an id-only payload can be found here .

With the server has activated content type of id-only , the subscription, it sets resources involved in triggering the status notification are only available through other channels (e.g., REST API), but notifications include URLs which can be used to "active" (note: access those resources. This allows servers to consolidate authorization and authentication logic, while removing the server can do need for expensive queries by subscribers. When a subscriber receives a notification of this as type, it accepts may directly fetch all the relevant resources using the supplied resource ids. For example, if it wants). the notification is for a topic about patient admission, the subscriber may fetch the Encounter(s) for a patient or group of patients.

An appropriately authorized client can use search and/or history operations to see what subscriptions are currently active on the server. Once When the subscription content type is no longer desired, id-only , the client deletes SubscriptionStatus.notificationEvent structure SHALL include references to the subscription from appropriate focus resources in the server. SubscriptionStatus.notificationEvent.focus element. This provides clients a fixed location to consolidate IDs for all notification types.

The server may retry Additionally, notification bundles MAY contain, in addition to the SubscriptionStatus , at least one Bundle.entry for each resource relevant to the notification. For example, a notification for a fixed number of times and/or refer errors topic based on Encounter MAY include a reference to its own alert logs. If the notification fails, Encounter and MAY also include additional resources deemed relevant (e.g., the server should set linked Patient).

2.13.6.3 full-resource

An example notification with a full-resource payload can be found here .

With the status to 'error' and mark content type of full-resource , the error resources involved in triggering the resource. If notification are included in the notification succeeds, bundle. When a subscriber receives a notification of this type, resources are already present in the server should update bundle, though the status subscriber may need to "active again. If a subscription fails consistently fetch additional resources from the server. For example, the if the notification is for a server topic about patient admission, the subscriber may choose set require related Observation resources.

When the subscription status content type is full-resource , the SubscriptionStatus.notificationEvent structure SHALL include references to off and stop trying the appropriate focus resources in the SubscriptionStatus.notificationEvent.focus element. This provides clients a fixed location to send notifications. consolidate IDs for all notification types.

Notification bundles for full-resource subscriptions SHALL contain, in addition to the SubscriptionStatus , at least one Bundle.entry for each resource relevant to the notification. For example, a notification for a topic based on Encounter SHALL include an Encounter and MAY include additional resources deemed relevant (e.g., the relevant Patient). Each Bundle.entry for a full-resource notification SHALL contain a relevant resource in the entry.resource element. If a subscription nominates server cannot include the resource contents due to an issue with a fixed end date, specific notification, the server automatically deletes it at SHALL populate the specified time. entry.request and/or entry.response elements.

2.46.7 2.13.7 Tracking Subscription Notifications Channels

2.13.7.1 Deciding on Channel Type

Applications that wish to track whether notifications have been sent for particular resources (or versions This specification defines a core set of resources) can look at channel types to cover the AuditEvent resources. For example: majority of common use cases. Servers MAY define additional channel types as needed. Below is some guidance for implementers to consider when selecting a channel type.

GET [base]/AuditEvent?entity=Patient/103

2.13.7.1.1 REST-Hook

This search will return all The FHIR standard makes extensive use of the AuditEvent resources that RESTful model. Given the popularity of REST and widespread adoption, most implementers should consider using REST-hook channels whenever possible. In general, REST-based systems are about Patient well-supported (e.g., tooling, infrastructure, documentation, etc.), and will present the lowest bar for implementation.

2.13.7.1.2 Websocket 103 . At this time there is no deterministic way to tell say which of those AuditEvent resources come from

Websockets are unique in the subscription sub-system pre-defined channel types in being the only channel that actually handles notifications. This is planned does not require the client to have an endpoint. Due to be resolved in a future version of this specification. In property, the mean time, servers are encouraged to create AuditEvent records when performing notifications and document how websocket channel is very useful for clients can identify the relevant records when searching. where creating an endpoint would be difficult or impossible (e.g., mobile clients, web-based clients, etc.).

In addition, servers might also create Communication

2.13.7.1.3 Email resources for some of

The Email channel is the notifications only channel that could contest REST in non-FHIR implementations. That said, Email communication is often high-latency and is typically used for communication to individuals - not applications. Email channels are sent particularly useful in response the context of these non-application use cases, such as public health notifications. For example, if a public health agency does not have the ability or desire to build a subscription, such custom RESTful solution (e.g., creating and maintaining an endpoint to receive notifications, as when sending emails. well as software to consume those notifications), it is straightforward to map notifications to email addresses or aliases.

GET [base]/Communication?based-on=Subscription/103

2.13.7.1.4 FHIR Messaging

This returns FHIR Messaging is a list of mechanism defined to allow for non-RESTful communication between FHIR servers and clients. One common use case is when connectivity is an issue (e.g., remote sites that batch all communications sent by a subscription. TODO: search on payload.... when connections are available). This channel defines how to integrate topic-based subscriptions with the FHIR Messaging model.

2.46.8 2.13.7.1.5 Custom Channels

For use cases that are not well-met by any of the predefined channels, the Subscriptions Framework allows for custom channel definitions. Some examples of scenarios where custom channels may be applicable include:

• requirements for reliable (guaranteed) delivery (e.g., message queues)
• implementations using other communication protocols (e.g., protocols specific to a cloud-based provider)
• implementations using a non-standard serialization format

2.46.8.1 2.13.7.2 REST Hook

This uses an empty POST message to alert the subscriber that new results are available - POST to [base]/Subscription: { "resourceType": "Subscription", "criteria": "Observation?name=http://loinc.org|1975-2&_format=json", "channel": { "type": "rest-hook", "endpoint": "https://biliwatch.com/customers/mount-auburn-miu/on-result", "header": ["Authorization: Bearer secret-token-abc-123"] } } When To receive notifications via HTTP/S POST, a resource is created or updated that meets client requests a subscription with the criteria, channel type of `rest-hook` (from the server sends a POST request subscription-channel-type Code System) and and an endpoint ( Subscription.endpoint ) with no body to the nominated desired URL. Note that this URL must be accessible by the hosting server.

When To convey an event notification, the subscriber receives server POSTs a POST to https://biliwatch.com/customers/mount-auburn-miu/on-result , it re-issues the criteria as a query notification Bundle to the server, appending client's nominated endpoint URL per the format requests in the Subscription:

• The &_since=:last content-type (where :last is replaced by of the time at which POST SHALL match the client last checked). In this way it can fetch all new relevant Observations MIME type on the Subscription Subscription.contentType .
• Each Subscription.header value SHALL be conveyed as an HTTP request header.

Since payload When a subscription is missing, the data in created for a REST Hook channel type, the resources is only available through server SHALL set initial status to requested , pending verification of the REST API, which helps consolidate authorization nominated endpoint URL. After a successful handshake notification has been sent and authentication logic. The accepted, the server must append SHALL update the headers, if any are given, status to active . Any errors in the POST request that it makes to initial handshake SHALL result in the client. status being changed to error .

Alternatively, the server can be asked to send the entire resource to a nominated FHIR end-point. This is usually appropriate An example workflow for defining routing rules within a managed eco-system such as establishing a healthcare institution. rest-hook subscription is shown below.

{ "channel": { "type": "rest-hook", "endpoint": "https://internal.acme.com/research/saturn", "payload": "application/fhir+json" } } This requests that

1. Client creates a copy of any matching resource in JSON format to the nominated server as an Update operation using the nominated URL as the service base . In order to execute this channel, Subscription with the server must know how channelType set to authenticate appropriately rest-hook .
2. Server responds with the destination server. This can be done by a success code and creates the subscription resource providing with a state of requested .
3. Server performs an authentication header for the server HTTP POST to use, or alternatively, the server may be specifically configured requested endpoint with a handshake notification.
4. Client Endpoint accepts the POST and returns a success HTTP code (e.g., 200 ).
5. Server sends a notification of type heartbeat at any time (SHOULD at least once per heartbeatPeriod ).
6. Client Endpoint accepts a heartbeat via HTTP POST and returns an HTTP success code (e.g., 200 ).
7. Server sends a notification of type event-notification when triggered.
8. Client Endpoint accepts an event-notification via HTTP POST and returns an HTTP code (e.g., 200 ).

2.13.7.2.1 Channel Security Notes

HTTP is neither a secure nor an encrypted channel, nor does it provide endpoint verification. It is strongly recommended that implementations refuse requests to be able send notifications to use URLs using the nominated server. HTTP protocol (use HTTPS instead).

2.46.8.2 2.13.7.3 WebSockets

Subscriptions are created exclusively via While the primary interface for FHIR servers is the FHIR REST API. But API, notifications need not occur via REST. Indeed, some subscribers may be unable to expose an outward-facing HTTP server to receive triggered notifications. For example, a pure client-side Web app or mobile app may want to subscribe to a data feed without polling using the /history operation. feed. This can be accomplished using a websocket notification channel. channel from the subscription-channel-type Code System.

A client can declare its intention to listen To receive notifications via Web Sockets: { "channel": { "type": "websocket" } } The subscriber would then initiate WebSocket, a Web Socket connection to the server, at client requests a URL advertised in subscription with the FHIR server's Capability statement (subscriptions/webSocketUrl (todo)). A simple protocol channel type ( Subscription.channelType ) of websocket (from the subscription-channel-type Code System). Note that no endpoint ( Subscription.endpoint ) is used in websocket channels, since clients connect to listen a server-hosted websocket URL.

An example workflow for notifications: receiving notifications via websockets is shown below:

1. Client connects creates a secure Web Socket Subscription with the channelType set to websocket .
2. Server responds with a success code and creates the server's webSocketUrl (see subscription.
3. Client requests a websocket extension in binding token, by invoking the server's CapabilityStatement $get-ws-binding-token ). operation via REST. Note: this call is intended to be repeated as necessary (e.g., prior to a token expiring, a client should request a new one).
4. Client authenticates parses the response of the $get-ws-binding-token operation to server using extract a server-specified Web socket protocol (e.g. OAuth bearer token presentation). , expiration , and websocket-url .
5. Client connects to the server via websockets, via the returned websocket-url ( wss:// preferred).
6. Client sends a bind :id bind-with-token message over via websockets, with the socket (using token provided by the logical id server. Note: this operation can be repeated concurrently for multiple subscriptions that share the same websocket-url , and serially for continued operation over a single websocket connection.
7. Server sends one or more handshake messages via websockets (one per Subscription included in the token). Note: some servers may additionally send one or more event-notification messages at this time (e.g., all messages since last connected, last 'n' messages, etc.). Clients are expected to handle either flow.
8. Server sends a notification of type heartbeat at any time (SHOULD at least once per heartbeatPeriod ).
9. Server sends a notification of type event-notification when triggered.
10. If the subscription). For example, token is expiring soon and the client might issue: bind 123). Client wishes to continue receiving notifications, it should invoke the $get-ws-binding-token operation via REST.
11. Server responds with at least a "bound :id" message token , expiration , and websocket-url . Note that the token and websocket-url MAY be the same or new values, as determined by the server.
12. If the websocket-url is different from the existing connection, the Client establishes a new connection to acknowledge. the Client Endpoint.
13. Server Client sends a "ping :id" bind-with-token message via websockets, with the token provided by the server. Note: this operation can be repeated concurrently for multiple subscriptions that return the same websocket-url , and serially for continued operation over a single websocket connection.
14. Server sends one or more handshake messages via websockets (one per Subscription included in the token). Note: some servers may additionally send one or more event-notification messages at this time (e.g., all messages since last connected, last 'n' messages, etc.). Clients are expected to notify handle either flow.
15. Either the server or the client each time may close the websocket connection.

Notes:

• Notifications sent from the server SHALL be in the MIME Type specified by the Subscription.contentType , however, if notifications are requested for multiple subscriptions with different MIME types, the server MAY choose to send all notifications in a new result single MIME type.
• Notifications SHALL conform to the content level specified by Subscription.content .
• When receiving notifications, a connected websocket client has no responsibilities beyond reading the message (e.g., there is available no acknowledgement message).

2.46.8.3

Note to Implementers: The Websocket channel type needs more testing and feedback to ensure all requirements are met before finalizing the specification.

2.13.7.3.1 Email/SMS Channel Security Notes

A WebSocket security poses several challenges specific to the channel. When implementing websockets for notifications, please keep in mind the following list of some areas of concern:

• Authentication of WebSockets is not generically interoperable with JWT or other 'Authentication header' protocols - the JavaScript WebSocket API does not include the ability to include them.
• Given client limitations on concurrent WebSocket connections (commonly 6), it is recommended that a single connection be able to authenticate to multiple Subscription resources.
• Unlike HTTP/S requests, WebSockets can register be long-lived. Because of this, the case of revoking access of an active connection must be considered.

2.13.7.4 Email

While the primary interface for its user FHIR servers is the FHIR REST API, notifications need not occur via REST. Indeed, some subscribers may be unable to maintain an outward-facing HTTP server to receive triggered notifications. For example, a public health organization may want to be notified of outbreaks of various illnesses. This can be accomplished using an email notification channel.

To receive notifications by email: via Email, a client requests a subscription with the channel type ( Subscription.channelType ) of email (from the subscription-channel-type Code System) and an endpoint ( Subscription.endpoint ) with the desired email URI (e.g., mailto:public_health_notifications@example.org ).

{ "channel": { "type": "email", "endpoint": "mailto:mt-auburn-results@direct.biliwatch.com", "header": ["A new bilirubin result has arrived!"] } }

The server would will send a new message for each matching resource. The body of the email may time a notification should be empty, sent (e.g., per event or it may contain per batch). The server will create a reference to message based on the search or values present in the matching resource. It is at Subscription.contentType and Subscription.content fields. If a server cannot honor the discretion of requested combination, the server as to how much information should reject the Subscription request rather than send unexpected email messages.

The email channel sets two guidelines about content:

• Message Body content SHALL be human readable
• Message Attachments SHOULD be machine readable

Due to provide. these guidelines, the Subscription.channel.header Subscription.contentType sets refers to the subject content of the email. The email should be secured appropriately, such as using Direct, as specified by the rules body of the applicable jurisdictions. SMS works very similarly: message. Attachment type information can be appended as a MIME parameter, for example:

{ "channel": { "type": "sms", "endpoint": "tel:+1555-345-5555" } }

• text/plain : a plain-text body with no attachment
• text/html : an HTML body with no attachment
• text/plain;attach=application/fhir+json : a plain-text body with a FHIR JSON bundle attached
• text/html;attach=application/fhir+xml : an HTML body with a FHIR XML bundle attached

Note: SMS messages are extremely limited in size, so The channel.payload Subscription.content will usually field SHALL be omitted (signifying that no payload is applied to any attachments, and MAY be sent). The recipient may be human, but this is applied to body contents (depending on server implementation). However, a server must not always include a body which exceeds the case. Irrespective of size, most servers will refuse specified content level. For example, a server may choose to send payloads always include a standard message in SMS for security reasons, the body of the message containing no PHI and may refuse vary the attachment, but cannot include PHI in the body of an email when the content is set to send emails unless encrypted. empty .

A mime/type of text/plain can be useful An example workflow using the email channel type is included below.

1. Client creates a Subscription with some extension describing how to convert resources the channelType set to email .
2. Server MAY respond with a text representation. This specification success code and create the subscription with a state of active .
3. Server MAY respond with a success code and create the subscription with a state of requested .
4. Server sends an initial message via the specified email server (e.g., verify the request, opt-out instructions, etc.).
5. Email Server responds with a channel appropriate response code (e.g., 250: OK ).
6. Server may provide supporting infrastructure send an email for this in the future. a notification of type heartbeat at any time (SHOULD at least once per heartbeatPeriod ).
7. Server may send an email for a notification of type event-notification at any time.

2.46.8.4 2.13.7.4.1 Channel Security Notes

Email (SMTP) is not a secure channel. Implementers must ensure that any messages containing PHI have been secured according to their policy requirements (e.g., use of a system such as Direct ).

2.13.7.5 Messaging

A client can register for its user There are times when it is desireable to use Subscriptions as a communication channel between FHIR servers that are connected via Messaging instead of REST. This can be accomplished using a Subscription with the channel type of message .

To receive notifications via messaging, a client should request a subscription with the channel type ( Subscription.channelType ) of message and set the endpoint ( Subscription.endpoint ) to the destination FHIR server base URL. Note that this URL must be accessible by messaging : the hosting server.

{ "channel": { "type": "message", "endpoint": "http://ehr.example.org/fhir/$process-message" } }

For each matching resource, a The FHIR server hosting the subscription (server) will send FHIR messages to the destination FHIR server (endpoint) as needed. These messages will, as the contents of the message, have a fully-formed subscription-notification Bundle. An example message can be found here .

An example workflow using the message channel type is included below.

1. Client creates a Subscription with the channelType set to message .
2. Server responds with a success code and creates the nominated end-point. Most servers will subscription with a state of requested .
3. Server sends a FHIR Message to the requested endpoint with a handshake notification.
4. Client Endpoint accepts the Message and returns success.
5. Server may send a Message containing a notification of type heartbeat at any time (SHOULD at least once per heartbeatPeriod ).
6. Server may send a Message containing a notification of type event-notification at any time.

Note to Implementers: The Messaging channel type needs more testing and feedback to ensure all requirements are met before finalizing the specification.

2.13.7.5.1 Channel Security Notes

Servers MAY require that the end-point is white-listed prior to allowing these kinds of subscriptions. Additionally, servers MAY impose authorization/authentication requirements for server to server communication (e.g., certificate pinning, etc.).

2.13.8 Defining Channel Types

Defining a new channel type requires clear communication to implementers of both clients and servers around requirements and expectations. Below are some areas which should be considered when creating a channel. Anyone defining a channel type is encouraged to publish their definition at registry.fhir.org .

STU Note: Note to Implementers: Warning: This section is still in early drafting; feedback from topic authors is welcome to refine the following guidance.

2.13.8.1 Channel Basics

At a minimum, the following items should be defined:

• A system for Subscription.channelType that reflects the publisher of the definition (e.g., "https://myorg.example.org" instead of "urn:uuid:be35238b-0ed6-4062-93cf-818b8023a103")
• A generally descriptive code for Subscription.channelType (e.g., 'secure-mq' instead of 'channel0012')
• The details type of data required in Subscription.endpoint (e.g., URI, etc.)
• The meaning of the message - mainly Subscription.header field values (e.g., REST-hook defines as Auth headers included in a POST)
• Any variations on MIME types for Subscription.contentType (e.g., email defines this as the event code - email body, with allowable attachments.)
• Whether handshake notifications are still used, and guidance on usage if they are
• Whether heartbeat notifications are used, and guidance on timings if they are

2.13.8.2 Channel Security Considerations

Defining a channel has security implications. While it is not expected that authors cover all aspects of security, guidance specific to the channel SHOULD be resolved during provided. For example, when discussing REST-hooks, this specification includes guidance about using HTTPS over HTTP.

If the trial channel CANNOT be secured, that should be stated with a warning not to transfer PHI. If the channel is or can be secured, guidance should be given on how configurations relate to PHI safety, for example:

• Does the channel determine the legitimacy of both endpoints?
• Is the channel secure from third-party monitoring?

2.13.9 Managing Subscriptions and Errors

The subscription resource is authored by the client with an initial status of requested . A new subscription is created on the server using the RESTful create or update interaction. After a successful transaction, the client parses the Location header and saves the new Subscription's logical id for use period. in subsequent operations.

Feedback When the server receives a subscription, it SHOULD check that it is welcome here prepared to accept/process the subscription. If it is, it sets the subscription to requested and process it like a normal create . If it isn't, it SHOULD return an error with an OperationOutcome instead of processing the create .

The criteria are subject to the same limitations as the client that created it, such as access to patient compartments etc. Note that the subscription MAY remain active after the client access tokens expire.

Once the server has activated the subscription, it sets the status to active (note: the server may do this as it accepts the resource if it wants).

An appropriately authorized client can use search and/or history operations to see what subscriptions are currently active on the server. Once the subscription is no longer desired, the client deletes the subscription from the server.

The server may retry the notification a fixed number of times and/or refer errors to its own alert logs. If the notification fails, the server SHOULD set the status to error and mark the error in the resource. If the notification succeeds, the server SHOULD update the status to active and may remove any error codes. If a subscription fails consistently a server may choose set the subscription status to off and stop trying to send notifications.

Errors a server wishes to make accessible to clients are stored in Subscription.error . Servers should provide a mechanism for clearing errors (e.g., when resetting a Subscription.status back to requested after an error). Since Subscription.error represents errors that a server has experienced, a server SHOULD NOT allow clients to add errors.

2.46.9 2.13.10 Search Parameters

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name	Type	Description	Expression	In Common
contact	token	Contact details for the subscription	Subscription.contact
criteria identifier	string token	The search rules used to determine when to send a notification A subscription identifier	Subscription.criteria Subscription.identifier
payload	token	The mime-type of the notification payload	Subscription.channel.payload
status	token	The current state of the subscription	Subscription.status
type	token	The type of channel for the sent notifications	Subscription.channel.type
url	uri	The uri that will receive the notifications	Subscription.channel.endpoint