This page is part of the FHIR Specification v4.3.0-snapshot1: R4B Snapshot to support the Jan 2022 Connectathon. About the R4B version of FHIR. The current officially released version is 4.3.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

• Content
• Examples
• Detailed Descriptions
• Mappings
• Profiles & Extensions
• R3 Conversions

2.46 Resource Subscription - Content

FHIR Infrastructure Work Group

Maturity Level: 3

Trial Use

Security Category: Business

Compartments: Not linked to any defined compartments

The subscription resource is used to define a push-based subscription from a server 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 a message on the defined "channel" so that another system can take an appropriate action.

2.46.3 References

This resource is referenced by SubscriptionStatus.

This resource does not implement any patterns.

2.46.4 Resource Content

 

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

2.46.4.1 Terminology Bindings

Path	Definition	Type	Reference
Subscription.status		Required	SubscriptionStatus
Subscription.channel.type		Required	SubscriptionChannelType
Subscription.channel.payload		Required	Mime Types

2.46.5 Safety and Security

Executing each of the channels documented below involves the server sending a communication that will reveal information about the client and server relationship, and, if the entire resource is sent, administrative or clinical information that may be quite sensitive and/or protected under law. Servers are responsible for ensuring appropriate security is employed 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, a server might maintain a whitelist of acceptable servers for the rest-create/rest-update methods.

Emails should generally be secured using some technique such as Direct .

2.46.6 Managing Subscriptions and Errors

A subscription is defined by creating the Subscription resource on the server. When the subscription is created by the client, it sets the status to "requested". After POSTing the subscription, the client parses the Location header and saves the new Subscription's logical id for use in subsequent operations.

When 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 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 remains active after the client access tokens expire.

Once the server has activated the subscription, it sets the status to "active" (note: the server can 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 again. If a subscription fails consistently a server may choose set the subscription status to off and stop trying to send notifications.

If a subscription nominates a fixed end date, the server automatically deletes it at the specified time.

2.46.7 Tracking Subscription Notifications

Applications that wish to track whether notifications have been sent for particular resources (or versions of resources) can look at the AuditEvent resources. For example:

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

This search will return all the AuditEvent resources that are about Patient 103. At this time there is no deterministic way to tell say which of those AuditEvent resources come from the subscription sub-system that actually handles notifications. This is planned to be resolved in a future version of this specification. In the mean time, servers are encouraged to create AuditEvent records when performing notifications and document how clients can identify the relevant records when searching.

In addition, servers might also create Communication resources for some of the notifications that are sent in response to a subscription, such as when sending emails.

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

This returns a list of communications sent by a subscription. TODO: search on payload....

2.46.8 Channels

2.46.8.1 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 a resource is created or updated that meets the criteria, the server sends a POST request with no body to the nominated URL.

When the subscriber receives a POST to https://biliwatch.com/customers/mount-auburn-miu/on-result, it re-issues the criteria as a query to the server, appending &_since=:last (where :last is replaced by the time at which the client last checked). In this way it can fetch all new relevant Observations.

Since payload is missing, the data in the resources is only available through the REST API, which helps consolidate authorization and authentication logic. The server must append the headers, if any are given, to the POST request that it makes to the client.

Alternatively, the server can be asked to send the entire resource to a nominated FHIR end-point. This is usually appropriate for defining routing rules within a managed eco-system such as a healthcare institution.

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

This requests that a server forward 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, the server must know how to authenticate appropriately with the destination server. This can be done by the subscription resource providing an authentication header for the server to use, or alternatively, the server may be specifically configured to be able to use the nominated server.

2.46.8.2 WebSockets

Subscriptions are created exclusively via the FHIR REST API. But 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. This can be accomplished using a websocket notification channel.

A client can declare its intention to listen via Web Sockets:

{
  "channel": {
    "type": "websocket"
  }
}

The subscriber would then initiate a Web Socket connection to the server, at a URL advertised in the FHIR server's Capability statement (subscriptions/webSocketUrl (todo)). A simple protocol is used to listen for notifications:

• Client connects a secure Web Socket to the server's webSocketUrl (see websocket extension in the server's CapabilityStatement).
• Client authenticates to server using a server-specified Web socket protocol (e.g. OAuth bearer token presentation).
• Client sends a bind :id message over the socket (using the logical id of the subscription). For example, the client might issue: bind 123).
• Server responds with a "bound :id" message to acknowledge.
• Server sends a "ping :id" message to notify the client each time a new result is available

2.46.8.3 Email/SMS

A client can register for its user to receive notifications by email:

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

The server would send a new message for each matching resource. The body of the email may be empty, or it may contain a reference to the search or the matching resource. It is at the discretion of the server as to how much information to provide. Subscription.channel.header sets the subject of the email. The email should be secured appropriately, such as using Direct, as specified by the rules of the applicable jurisdictions.

SMS works very similarly:

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

Note: SMS messages are extremely limited in size, so channel.payload will usually be omitted (signifying that no payload is to be sent). The recipient may be human, but this is not always the case. Irrespective of size, most servers will refuse to send payloads in SMS for security reasons, and may refuse to send emails unless encrypted.

A mime/type of text/plain can be useful for email and sms along with some extension describing how to convert resources to a text representation. This specification may provide supporting infrastructure for this in the future.

2.46.8.4 Messaging

A client can register for its user to receive notifications by messaging:

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

For each matching resource, a server will send a message to the nominated end-point. Most servers will require that the end-point is white-listed prior to allowing these kinds of subscriptions.

STU Note: The details of the message - mainly the event code - are still to be resolved during the trial use period.

Feedback is welcome here .

2.46.9 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	string	The search rules used to determine when to send a notification	Subscription.criteria
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