View raw Markdown
type: resourceresource: SubscriptionStatus

SubscriptionStatus

Introduction

Scope and Usage

This document contains information about the SubscriptionStatus resource and details specific to options in it. See Subscriptions for general information about using Subscriptions in FHIR.

The SubscriptionStatus resource is used to convey information about the current state of a Subscription during client notifications. It is not persisted or allowed to be referenced by other resources except as described below.

Boundaries and Relationships

The SubscriptionStatus resource is used in the Subscriptions Framework. Information about the Boundaries and Relationships both within the Subscriptions Framework and to other areas of the FHIR specification can be found here.

Notes

Timing and Currency

This resource is used to communicate information about a Subscription and the events represented by a notification bundle. The process of sending a notification (e.g., a notification this status is included with) can change the status of that subscription. Servers SHALL populate elements with the most recent information at the time of generation (e.g., when a notification is created) and receivers SHOULD be aware that this information might not be current at the time a notification is processed (e.g., a subscription was active but has subsequently moved to an error state).

Content and PHI (Personal health information)

Subscription notifications MAY contain PHI. Applications are responsible for following FHIR security guidance and compliance with relevant security requirements (e.g., corporate policy, government regulation, etc.). Hinting for the allowed amount of PHI is available in the relevant Subscription resource, via the channel and payload information.

Since Subscription Topic definitions contain human-readable descriptions and definitions, the purpose of a topic may be understood by viewing the resource. Given that canonical links to topics are intended to be resolvable and/or searchable (e.g., indexed in a registry), it is assumed that anyone with a link to a topic also knows what that topic is about. Thus, topics MAY be considered PHI and SHOULD be reviewed before inclusion in a notification.

Hinting about when a canonical topic URL may be included with a notification can be derived from a subscription's payload level. E.g.:

Subscription Reference

The SubscriptionStatus.subscription element contains a reference to the Subscription resource responsible for the notification. In most cases, this reference will resolve to an accessible Subscription resource on the server. However, in some workflows, particularly those involving implicit or server-controlled subscriptions, the Subscription resource might not be externally accessible or shared. In such cases, the Reference may use Reference.identifier to represent an identifier or placeholder known only to the sender, or even Reference.display for a relevant literal (e.g., friendly-name that can be referenced in support requests). Implementers SHOULD be aware that resolution of this reference might not be possible on the receiving end.

Event Numbering

Since this specification does not currently define any channel types that guarantee client receipt of notifications, a monotonically-increasing event number is critical to detecting several classes of delivery errors (more information is available at Detecting Delivery Errors). However, with the availability of custom-defined channels, notifications can be sent across channels that provide guaranteed delivery (e.g., a message queue), which removes the need for global tracking of event numbers.

For channels that do not need event numbers, it is still desirable for clients to have an index for the events present in a notification. In all cases, a value for SubscriptionStatus.notificationEvent.eventNumber is required - either the number in-sequence based on the total number of events on a subscription or a notification-bundle relative index (e.g., 1, 2, 3, etc.).

ElementDelivery TypeOptionalityNotes
SubscriptionStatus.eventsSinceSubscriptionStartBest EffortRequiredServers SHALL include this value when sending event notifications in order to allow clients to detect missing events. <br/> This value is inclusive of this notification (e.g., the first event notification sent would include one (1) in this element).
SubscriptionStatus.eventsSinceSubscriptionStartGuaranteedOptionalServers MAY include this value when sending event notifications.
SubscriptionStatus.notificationEvent.eventNumberBest EffortRequiredEvent numbers SHALL match the index in the subscription event sequence. E.g., the highest-numbered event in the notification will match the number in eventsSinceSubscriptionStart.
SubscriptionStatus.notificationEvent.eventNumberGuaranteedRequiredA relative index of events in a single notification, e.g., 1, 2, 3, etc..

Notification Types

This specification describes five distinct outbound notification types: Event, Handshake, Heartbeat, Query Status, and Query Event. For each, the notification body is a subscription-notification Bundle with a SubscriptionStatus resource used to convey Subscription and notification details.

Event Notification

The primary notification bundle type is a notification about an event.

ElementOptionalityNotes
SubscriptionStatus.statusRecommendedCurrent status of the relevant subscription (e.g., active).
SubscriptionStatus.typeRequiredSHALL be event-notification
SubscriptionStatus.eventsSinceSubscriptionStartSpecialRequired for subscriptions with best-effort delivery, optional for subscriptions with guaranteed delivery. See Event Numbering for details.
SubscriptionStatus.notificationEventRequiredFor notifications that include events, this element SHALL be present. Details about specific elements within this structure are included in this table.
SubscriptionStatus.notificationEvent.eventNumberSpecialRequired for subscriptions with best-effort delivery, optional for subscriptions with guaranteed delivery. See Event Numbering for details.
SubscriptionStatus.notificationEvent.timestampRecommendedSo that clients can discover when an event actually occurred, timestamp is recommended.
SubscriptionStatus.notificationEvent.focusSpecialLinks contained in the focus element contain resource IDs, so will or will not be present based on the payload level relevant to the notification:

Note that servers SHOULD include the Reference.type element if if the type is not specified in Reference.reference | | SubscriptionStatus.notificationEvent.additionalContext | Special | Links contained in the additionalContext element contain resource IDs and MAY or MAY NOT exist. Presence is determined based on the payload level relevant to the notification, if they are available:

Note that servers SHOULD include the Reference.type element if if the type is not specified in Reference.reference | | SubscriptionStatus.topic | Optional | See Content and PHI. |

Handshake Notification

When a connection to an Endpoint is established or re-established, a server MAY send a Handshake notification to the endpoint.

The client expectations upon receipt of a Handshake notification differ for each channel type (e.g., for the rest-hook channel type, a client endpoint responds to event notifications with standard HTTP response codes).

ElementOptionalityNotes
SubscriptionStatus.statusRecommendedCurrent status of the relevant subscription (e.g., active).
SubscriptionStatus.typeRequiredSHALL be handshake
SubscriptionStatus.eventsSinceSubscriptionStartOptionalFor a new Subscription, if this value is present it SHALL be zero (0).
A sender MAY send a handshake with a non-zero number of events, for example as process for re-establishing communication after an error state.
Note: this value SHALL NOT be incremented by sending a handshake notification.
SubscriptionStatus.notificationEventSpecialA server MAY include historical events for a client with a handshake, if any exist. For example, during a reconnection process, a server MAY opt to include all events since the last successful transmission to the client. Details about specific elements within this structure are included in this table.
SubscriptionStatus.notificationEvent.eventNumberSpecialRequired for subscriptions with best-effort delivery, optional for subscriptions with guaranteed delivery. See Event Numbering for details.
SubscriptionStatus.notificationEvent.timestampSpecialIf a server is including prior events, timestamp is recommended, so that clients can process historical events with proper context.
SubscriptionStatus.notificationEvent.focusSpecialLinks contained in the focus element contain resource IDs, so will or will not be present based on the payload level relevant to the notification:

Note that servers SHOULD include the Reference.type element if if the type is not specified in Reference.reference | | SubscriptionStatus.notificationEvent.additionalContext | Special | Links contained in the additionalContext element contain resource IDs and MAY or MAY NOT exist. Presence is determined based on the payload level relevant to the notification, if they are available:

Note that servers SHOULD include the Reference.type element if if the type is not specified in Reference.reference | | SubscriptionStatus.topic | Optional | See Content and PHI. |

The client is not expected to take any special action in receipt of a Handshake notification beyond the channel-specific requirement for receiving an event notification.

Heartbeat Notification

A heartbeat notification is a subscription-notification Bundle of type heartbeat sent without incrementing the subscription event count, though servers MAY include the most recent event in the notification. For servers, heartbeat notifications allow systems to ensure that the connection is still alive and valid. For clients, heartbeat notifications serve as a method to detect errors in communication. Note that a client is not required to take any action in receipt of a heartbeat beyond the channel-specific requirement for receiving an event notification (e.g., accepting the notification bundle with an HTTP 200).

Heartbeat intervals are negotiated while creating a Subscription. If accepted, servers SHOULD send a heartbeat notification whenever the channel has been inactive for the specified amount of time. For example, if the heartbeat interval is 60 seconds, the expectation is that there is never a period of 60 seconds that passes without sending at least one notification (either event-notification or heartbeat). Note that this is a minimum requirement - servers have discretion on how to implement testing: for example by resetting a timer when sending any notification, always sending a heartbeat on a fixed timer, etc.. Clients SHALL be able to handle receiving heartbeat notifications more often than required, and SHOULD account for miniscule differences timing (e.g., clock drift).

ElementOptionalityNotes
SubscriptionStatus.statusRecommendedCurrent status of the relevant subscription (e.g., active).
SubscriptionStatus.typeRequiredSHALL be heartbeat
SubscriptionStatus.eventsSinceSubscriptionStartRecommendedThe presence of this value allows clients to detect missing notifications. Recommended for subscriptions with best-effort delivery, optional for subscriptions with guaranteed delivery. <br/> Note: this value SHALL NOT be incremented by sending a heartbeat notification.
SubscriptionStatus.notificationEventSpecialA server MAY include historical events for a client with a heartbeat, if any exist. For example, a server MAY opt to include the most recent event since the last successful transmission to the client. Details about specific elements within this structure are included in this table.
SubscriptionStatus.notificationEvent.eventNumberSpecialIf a server is including any prior events, this element is required for subscriptions with best-effort delivery and optional for subscriptions with guaranteed delivery. See Event Numbering for details.
SubscriptionStatus.notificationEvent.timestampSpecialIf a server is including any prior events, timestamp is recommended, so that clients can process historical events with proper context.
SubscriptionStatus.notificationEvent.focusSpecialLinks contained in the focus element contain resource IDs, so will or will not be present based on the payload level relevant to the notification:

Note that servers SHOULD include the Reference.type element if if the type is not specified in Reference.reference | | SubscriptionStatus.notificationEvent.additionalContext | Special | Links contained in the additionalContext element contain resource IDs and MAY or MAY NOT exist. Presence is determined based on the payload level relevant to the notification, if they are available:

Note that servers SHOULD include the Reference.type element if if the type is not specified in Reference.reference | | SubscriptionStatus.topic | Optional | See Content and PHI. |

Query Status

Clients can ask a server at any time for the current status of a Subscription, for example via the $status operation.

Since the $status operation is part of the FHIR REST API, the guidance below assumes that a user has been authenticated and is allowed access to all relevant resources.

ElementOptionalityNotes
SubscriptionStatus.statusRequiredCurrent status of the relevant subscription (e.g., active).
SubscriptionStatus.typeRequiredSHALL be query-status
SubscriptionStatus.eventsSinceSubscriptionStartSpecialRequired for subscriptions with best-effort delivery, optional for subscriptions with guaranteed delivery. See Event Numbering for details. <br/> Note: this value SHALL NOT be incremented by sending a query-status notification.
SubscriptionStatus.notificationEventSpecialA query-status notification MAY contain recent notifications.
SubscriptionStatus.topicRecommendedSee Content and PHI, but note that guidance will vary since there is an active user session.

Query Event

Some servers may allow clients to ask for events which have already occurred, for example via the $events operation.

Since the $events operation is part of the FHIR REST API, the guidance below assumes that a user has been authenticated and the server has filtered any results according to what the user is allowed access.

ElementOptionalityNotes
SubscriptionStatus.statusRecommendedCurrent status of the relevant subscription (e.g., active).
SubscriptionStatus.typeRequiredSHALL be query-event.
SubscriptionStatus.eventsSinceSubscriptionStartRecommendedThis value is allows clients to know if they are missing notifications. Recommended for subscriptions with best-effort delivery and optional for subscriptions with guaranteed delivery.
Note: this value SHALL NOT be incremented by sending a query-event bundle.
See Event Numbering for more information.
SubscriptionStatus.notificationEventRequiredFor notifications that include events, this element SHALL be present. Details about specific elements within this structure are included in this table.
SubscriptionStatus.notificationEvent.eventNumberSpecialRequired for subscriptions with best-effort delivery, optional for subscriptions with guaranteed delivery. See Event Numbering for details.
SubscriptionStatus.notificationEvent.timestampRecommendedSo that clients can discover when an event actually occurred, timestamp is recommended.
SubscriptionStatus.notificationEvent.focusSpecialLinks contained in the focus element contain resource IDs, so will or will not be present based on the payload level relevant to the notification:

Note that servers SHOULD include the Reference.type element if if the type is not specified in Reference.reference | | SubscriptionStatus.notificationEvent.additionalContext | Special | Links contained in the additionalContext element contain resource IDs and MAY or MAY NOT exist. Presence is determined based on the payload level relevant to the notification, if they are available:

Note that servers SHOULD include the Reference.type element if if the type is not specified in Reference.reference | | SubscriptionStatus.topic | Recommended | See Content and PHI, but note that guidance will vary since there is an active user session. |

Notifications and Errors

The SubscriptionStatus resource is key in detecting various errors in communication and processing. For more information, see Managing Subscriptions and Errors in the Subscriptions Framework page.

StructureDefinition

Elements (Simplified)

Mappings

Resource Packs

list-SubscriptionStatus-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir">
  <id value="SubscriptionStatus-packs"/>
  <status value="current"/>
  <mode value="working"/>
</List>

Examples

Full Examples

Mapping Exceptions

subscriptionstatus-fivews-mapping-exceptions.xml

Divergent Elements

Unmapped Elements