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

2.47 Resource SubscriptionStatus - Content

FHIR Infrastructure

Work Group

Maturity Level: 0

Draft

Security Category: Business

Compartments: Not linked to any defined compartments

The SubscriptionStatus resource describes the state of a Subscription during notifications.

2.47.1 Scope and Usage

This document contains information about the SubscriptionStatus resource and details specific to options in it. It is defined as part of the Pub/Sub (Publish / Subscribe) model of Subscriptions.

The SubscriptionStatus resource is used to convey information about the current state of a Subscription. Information contained within a SubscriptionStatus falls into three categories:

Information to identify the relevant Subscription (e.g., a reference to a Subscription, SubscriptionTopic)
Information about the current state of the Subscription (e.g., Subscription status, number of events the Subscription has generated)
Information about a current notification (e.g., notification type, number of events in this notification)

2.47.2 Boundaries and Relationships

The SubscriptionStatus resource is used in the Subscriptions Framework. This resource is designed only to be used to convey state information about a subscription during various operations, for example included with notifications or as the result of a status request.

2.47.3 References

No resources refer to this resource directly.

This resource does not implement any patterns.

Structure

Name	Flags	Card.	Type	Description & Constraints
SubscriptionStatus	D		DomainResource	Status information about a Subscription provided during event notification Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
status	Σ	0..1	code	requested \| active \| error \| off \| entered-in-error SubscriptionStatus (Required)
type	?!Σ	1..1	code	handshake \| heartbeat \| event-notification \| query-status \| query-event SubscriptionNotificationType (Required)
eventsSinceSubscriptionStart	Σ	0..1	string	Events since the Subscription was created
eventsInNotification	Σ	0..1	integer	The number of actual notifications represented by this bundle
notificationEvent		0..*	BackboneElement	Detailed information about any events relevant to this notification
eventNumber		1..1	string	Event number
timestamp		0..1	instant	The instant this event occurred
focus		0..1	Reference(Any)	The focus of this event
additionalContext		0..*	Reference(Any)	Additional context for this event
subscription	Σ	1..1	Reference(Subscription)	Reference to the Subscription responsible for this notification
topic	Σ	0..1	canonical(SubscriptionTopic)	Reference to the SubscriptionTopic this notification relates to
error	Σ	0..*	CodeableConcept	List of errors on the subscription Subscription Error Codes (Example)
Documentation for this format

UML Diagram (Legend)

XML Template

<SubscriptionStatus xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <status value="[code]"/><!-- 0..1 requested | active | error | off | entered-in-error -->
 <type value="[code]"/><!-- 1..1 handshake | heartbeat | event-notification | query-status | query-event -->
 <eventsSinceSubscriptionStart value="[string]"/><!-- 0..1 Events since the Subscription was created -->
 <eventsInNotification value="[integer]"/><!-- 0..1 The number of actual notifications represented by this bundle -->
 <notificationEvent>  <!-- 0..* Detailed information about any events relevant to this notification -->
  <eventNumber value="[string]"/><!-- 1..1 Event number -->
  <timestamp value="[instant]"/><!-- 0..1 The instant this event occurred -->
  <focus><!-- 0..1 Reference(Any) The focus of this event --></focus>
  <additionalContext><!-- 0..* Reference(Any) Additional context for this event --></additionalContext>
 </notificationEvent>
 <subscription><!-- 1..1 Reference(Subscription) Reference to the Subscription responsible for this notification --></subscription>
 <topic><!-- 0..1 canonical(SubscriptionTopic) Reference to the SubscriptionTopic this notification relates to --></topic>
 <error><!-- 0..* CodeableConcept List of errors on the subscription --></error>
</SubscriptionStatus>

JSON Template

{
  "resourceType" : "SubscriptionStatus",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "status" : "<code>", // requested | active | error | off | entered-in-error
  "type" : "<code>", // R!  handshake | heartbeat | event-notification | query-status | query-event
  "eventsSinceSubscriptionStart" : "<string>", // Events since the Subscription was created
  "eventsInNotification" : <integer>, // The number of actual notifications represented by this bundle
  "notificationEvent" : [{ // Detailed information about any events relevant to this notification
    "eventNumber" : "<string>", // R!  Event number
    "timestamp" : "<instant>", // The instant this event occurred
    "focus" : { Reference(Any) }, // The focus of this event
    "additionalContext" : [{ Reference(Any) }] // Additional context for this event
  }],
  "subscription" : { Reference(Subscription) }, // R!  Reference to the Subscription responsible for this notification
  "topic" : { canonical(SubscriptionTopic) }, // Reference to the SubscriptionTopic this notification relates to
  "error" : [{ CodeableConcept }] // List of errors on the subscription
}

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .


[ a fhir:SubscriptionStatus;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:SubscriptionStatus.status [ code ]; # 0..1 requested | active | error | off | entered-in-error
  fhir:SubscriptionStatus.type [ code ]; # 1..1 handshake | heartbeat | event-notification | query-status | query-event
  fhir:SubscriptionStatus.eventsSinceSubscriptionStart [ string ]; # 0..1 Events since the Subscription was created
  fhir:SubscriptionStatus.eventsInNotification [ integer ]; # 0..1 The number of actual notifications represented by this bundle
  fhir:SubscriptionStatus.notificationEvent [ # 0..* Detailed information about any events relevant to this notification
    fhir:SubscriptionStatus.notificationEvent.eventNumber [ string ]; # 1..1 Event number
    fhir:SubscriptionStatus.notificationEvent.timestamp [ instant ]; # 0..1 The instant this event occurred
    fhir:SubscriptionStatus.notificationEvent.focus [ Reference(Any) ]; # 0..1 The focus of this event
    fhir:SubscriptionStatus.notificationEvent.additionalContext [ Reference(Any) ], ... ; # 0..* Additional context for this event
  ], ...;
  fhir:SubscriptionStatus.subscription [ Reference(Subscription) ]; # 1..1 Reference to the Subscription responsible for this notification
  fhir:SubscriptionStatus.topic [ canonical(SubscriptionTopic) ]; # 0..1 Reference to the SubscriptionTopic this notification relates to
  fhir:SubscriptionStatus.error [ CodeableConcept ], ... ; # 0..* List of errors on the subscription
]

Changes since R3

This resource did not exist in Release 2

This analysis is available as XML or JSON.

Structure

Name	Flags	Card.	Type	Description & Constraints
SubscriptionStatus	D		DomainResource	Status information about a Subscription provided during event notification Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
status	Σ	0..1	code	requested \| active \| error \| off \| entered-in-error SubscriptionStatus (Required)
type	?!Σ	1..1	code	handshake \| heartbeat \| event-notification \| query-status \| query-event SubscriptionNotificationType (Required)
eventsSinceSubscriptionStart	Σ	0..1	string	Events since the Subscription was created
eventsInNotification	Σ	0..1	integer	The number of actual notifications represented by this bundle
notificationEvent		0..*	BackboneElement	Detailed information about any events relevant to this notification
eventNumber		1..1	string	Event number
timestamp		0..1	instant	The instant this event occurred
focus		0..1	Reference(Any)	The focus of this event
additionalContext		0..*	Reference(Any)	Additional context for this event
subscription	Σ	1..1	Reference(Subscription)	Reference to the Subscription responsible for this notification
topic	Σ	0..1	canonical(SubscriptionTopic)	Reference to the SubscriptionTopic this notification relates to
error	Σ	0..*	CodeableConcept	List of errors on the subscription Subscription Error Codes (Example)
Documentation for this format

UML Diagram (Legend)

XML Template

<SubscriptionStatus xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <status value="[code]"/><!-- 0..1 requested | active | error | off | entered-in-error -->
 <type value="[code]"/><!-- 1..1 handshake | heartbeat | event-notification | query-status | query-event -->
 <eventsSinceSubscriptionStart value="[string]"/><!-- 0..1 Events since the Subscription was created -->
 <eventsInNotification value="[integer]"/><!-- 0..1 The number of actual notifications represented by this bundle -->
 <notificationEvent>  <!-- 0..* Detailed information about any events relevant to this notification -->
  <eventNumber value="[string]"/><!-- 1..1 Event number -->
  <timestamp value="[instant]"/><!-- 0..1 The instant this event occurred -->
  <focus><!-- 0..1 Reference(Any) The focus of this event --></focus>
  <additionalContext><!-- 0..* Reference(Any) Additional context for this event --></additionalContext>
 </notificationEvent>
 <subscription><!-- 1..1 Reference(Subscription) Reference to the Subscription responsible for this notification --></subscription>
 <topic><!-- 0..1 canonical(SubscriptionTopic) Reference to the SubscriptionTopic this notification relates to --></topic>
 <error><!-- 0..* CodeableConcept List of errors on the subscription --></error>
</SubscriptionStatus>

JSON Template

{
  "resourceType" : "SubscriptionStatus",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "status" : "<code>", // requested | active | error | off | entered-in-error
  "type" : "<code>", // R!  handshake | heartbeat | event-notification | query-status | query-event
  "eventsSinceSubscriptionStart" : "<string>", // Events since the Subscription was created
  "eventsInNotification" : <integer>, // The number of actual notifications represented by this bundle
  "notificationEvent" : [{ // Detailed information about any events relevant to this notification
    "eventNumber" : "<string>", // R!  Event number
    "timestamp" : "<instant>", // The instant this event occurred
    "focus" : { Reference(Any) }, // The focus of this event
    "additionalContext" : [{ Reference(Any) }] // Additional context for this event
  }],
  "subscription" : { Reference(Subscription) }, // R!  Reference to the Subscription responsible for this notification
  "topic" : { canonical(SubscriptionTopic) }, // Reference to the SubscriptionTopic this notification relates to
  "error" : [{ CodeableConcept }] // List of errors on the subscription
}

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .


[ a fhir:SubscriptionStatus;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:SubscriptionStatus.status [ code ]; # 0..1 requested | active | error | off | entered-in-error
  fhir:SubscriptionStatus.type [ code ]; # 1..1 handshake | heartbeat | event-notification | query-status | query-event
  fhir:SubscriptionStatus.eventsSinceSubscriptionStart [ string ]; # 0..1 Events since the Subscription was created
  fhir:SubscriptionStatus.eventsInNotification [ integer ]; # 0..1 The number of actual notifications represented by this bundle
  fhir:SubscriptionStatus.notificationEvent [ # 0..* Detailed information about any events relevant to this notification
    fhir:SubscriptionStatus.notificationEvent.eventNumber [ string ]; # 1..1 Event number
    fhir:SubscriptionStatus.notificationEvent.timestamp [ instant ]; # 0..1 The instant this event occurred
    fhir:SubscriptionStatus.notificationEvent.focus [ Reference(Any) ]; # 0..1 The focus of this event
    fhir:SubscriptionStatus.notificationEvent.additionalContext [ Reference(Any) ], ... ; # 0..* Additional context for this event
  ], ...;
  fhir:SubscriptionStatus.subscription [ Reference(Subscription) ]; # 1..1 Reference to the Subscription responsible for this notification
  fhir:SubscriptionStatus.topic [ canonical(SubscriptionTopic) ]; # 0..1 Reference to the SubscriptionTopic this notification relates to
  fhir:SubscriptionStatus.error [ CodeableConcept ], ... ; # 0..* List of errors on the subscription
]

Changes since Release 3

This resource did not exist in Release 2

This analysis is available as XML or JSON.

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.47.4.1 Terminology Bindings

Path	Type	Reference
SubscriptionStatus.status	Required	SubscriptionStatus
SubscriptionStatus.type	Required	SubscriptionNotificationType
SubscriptionStatus.error	Example	SubscriptionErrorCodes

Path

Definition

Type

Reference

SubscriptionStatus.status

Required

SubscriptionStatus

SubscriptionStatus.type

Required

SubscriptionNotificationType

SubscriptionStatus.error

Example

SubscriptionErrorCodes

2.47.5 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 may not be current at the time a notification is processed (e.g., a subscription was active but has subsequently moved to an error state).

2.47.6 Content and PHI

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.:

empty: SHOULD NOT be present
id-only: MAY be present
full-resource: SHOULD be present

2.47.7 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.

2.47.7.1 Event Notification

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

Element Optionality Notes

SubscriptionStatus.status Recommended Current status of the relevant subscription (e.g., active).

SubscriptionStatus.type Required SHALL be event-notification

SubscriptionStatus.eventsSinceSubscriptionStart Recommended Servers SHOULD include this value when sending event notifications in order to allow clients to detect missing events.
This value is inclusive of this notification (e.g., the first event notification sent would include one (1) in this element).

SubscriptionStatus.eventsInNotification Recommended Servers SHOULD include this value when sending event notifications to ease client processing.

SubscriptionStatus.notificationEvent

Special

Element	Optionality	Notes
SubscriptionStatus.status	Recommended	Current status of the relevant subscription (e.g., `active`).
SubscriptionStatus.type	Required	SHALL be `event-notification`
SubscriptionStatus.eventsSinceSubscriptionStart	Recommended	Servers SHOULD include this value when sending event notifications in order to allow clients to detect missing events. This value is inclusive of this notification (e.g., the first event notification sent would include one (1) in this element).
SubscriptionStatus.eventsInNotification	Recommended	Servers SHOULD include this value when sending event notifications to ease client processing.
SubscriptionStatus.notificationEvent	Special	In general, filling out the `eventNumber` and `timestamp` is recommended. Links contained in the `focus` and `additionalContext` elements contain resource IDs and should mirror the payload level used in the subscription: `empty`: SHOULD NOT be present `id-only`: SHOULD be present `full-resource`: SHOULD be present
SubscriptionStatus.topic	Optional	See Content and PHI.

In general, filling out the eventNumber and timestamp is recommended. Links contained in the focus and additionalContext elements contain resource IDs and should mirror the payload level used in the subscription:

empty: SHOULD NOT be present
id-only: SHOULD be present
full-resource: SHOULD be present

SubscriptionStatus.topic Optional See Content and PHI.

Example event notification

2.47.7.2 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).

Element Optionality Notes

SubscriptionStatus.status Recommended Current status of the relevant subscription (e.g., active).

SubscriptionStatus.type Required SHALL be handshake

SubscriptionStatus.eventsSinceSubscriptionStart Optional For 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.eventsInNotification Optional If present, this value SHALL be zero (0).

SubscriptionStatus.notificationEvent Prohibited A handshake notification SHALL NOT contain any event information.

SubscriptionStatus.topic Optional See Content and PHI.

Element	Optionality	Notes
SubscriptionStatus.status	Recommended	Current status of the relevant subscription (e.g., `active`).
SubscriptionStatus.type	Required	SHALL be `handshake`
SubscriptionStatus.eventsSinceSubscriptionStart	Optional	For 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.eventsInNotification	Optional	If present, this value SHALL be zero (0).
SubscriptionStatus.notificationEvent	Prohibited	A `handshake` notification SHALL NOT contain any event information.
SubscriptionStatus.topic	Optional	See Content and PHI.

Example handshake notification

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.

2.47.7.3 Heartbeat Notification

Servers MAY periodically send notifications across a channel to ensure that the connection is still alive and valid (e.g., in accordance with a client's requested heartbeat interval). A heartbeat notification is an empty subscription-notification Bundle sent without incrementing the subscription event count.

A client SHOULD use a hearbeat notification to verify that no events have been missed (if possible). However, 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).

Element Optionality Notes

SubscriptionStatus.status Recommended Current status of the relevant subscription (e.g., active).

SubscriptionStatus.type Required SHALL be heartbeat

SubscriptionStatus.eventsSinceSubscriptionStart Recommended The presence of this value allows clients to detect missing notifications.
Note: this value SHALL NOT be incremented by sending a heartbeat notification.

SubscriptionStatus.eventsInNotification Optional If present, this value SHALL be zero (0).

SubscriptionStatus.notificationEvent Prohibited A heartbeat notification SHALL NOT contain any event information.

SubscriptionStatus.topic Optional See Content and PHI.

Element	Optionality	Notes
SubscriptionStatus.status	Recommended	Current status of the relevant subscription (e.g., `active`).
SubscriptionStatus.type	Required	SHALL be `heartbeat`
SubscriptionStatus.eventsSinceSubscriptionStart	Recommended	The presence of this value allows clients to detect missing notifications. Note: this value SHALL NOT be incremented by sending a `heartbeat` notification.
SubscriptionStatus.eventsInNotification	Optional	If present, this value SHALL be zero (0).
SubscriptionStatus.notificationEvent	Prohibited	A `heartbeat` notification SHALL NOT contain any event information.
SubscriptionStatus.topic	Optional	See Content and PHI.

Example heartbeat notification

2.47.7.4 Query Status

Clients can ask a server at any time for the current status of a Subscription 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.

Element Optionality Notes

SubscriptionStatus.status Required Current status of the relevant subscription (e.g., active).

SubscriptionStatus.type Required SHALL be query-status

SubscriptionStatus.eventsSinceSubscriptionStart Required This value is required for clients to know if there are missing notifications.
Note: this value SHALL NOT be incremented by sending a query-status notification.

SubscriptionStatus.eventsInNotification Optional If present, this value SHALL be zero (0).

SubscriptionStatus.notificationEvent Prohibited A query-status notification SHALL NOT contain any event information.

SubscriptionStatus.topic Recommended See Content and PHI, but note that guidance will vary since there is an active user session.

Element	Optionality	Notes
SubscriptionStatus.status	Required	Current status of the relevant subscription (e.g., `active`).
SubscriptionStatus.type	Required	SHALL be `query-status`
SubscriptionStatus.eventsSinceSubscriptionStart	Required	This value is required for clients to know if there are missing notifications. Note: this value SHALL NOT be incremented by sending a `query-status` notification.
SubscriptionStatus.eventsInNotification	Optional	If present, this value SHALL be zero (0).
SubscriptionStatus.notificationEvent	Prohibited	A `query-status` notification SHALL NOT contain any event information.
SubscriptionStatus.topic	Recommended	See Content and PHI, but note that guidance will vary since there is an active user session.

Example query-status notification

2.47.7.5 Query Event

Some servers may allow clients to ask for events which have already occurred. Notification bundles returned by such operations or queries should use the query-event type.

Element Optionality Notes

SubscriptionStatus.status Recommended Current status of the relevant subscription (e.g., active).

SubscriptionStatus.type Required SHALL be query-event

SubscriptionStatus.eventsSinceSubscriptionStart Recommended This value is allows clients to know if they are missing notifications.
Note: this value SHALL NOT be incremented by sending a query-event bundle.

SubscriptionStatus.eventsInNotification Required The number of events actually returned by this operation request.

SubscriptionStatus.notificationEvent Recommended A query-event notification SHOULD contain as much event information as possible, to simplify client processing.

SubscriptionStatus.topic Recommended See Content and PHI, but note that guidance will vary since there is an active user session.

Element	Optionality	Notes
SubscriptionStatus.status	Recommended	Current status of the relevant subscription (e.g., `active`).
SubscriptionStatus.type	Required	SHALL be `query-event`
SubscriptionStatus.eventsSinceSubscriptionStart	Recommended	This value is allows clients to know if they are missing notifications. Note: this value SHALL NOT be incremented by sending a `query-event` bundle.
SubscriptionStatus.eventsInNotification	Required	The number of events actually returned by this operation request.
SubscriptionStatus.notificationEvent	Recommended	A `query-event` notification SHOULD contain as much event information as possible, to simplify client processing.
SubscriptionStatus.topic	Recommended	See Content and PHI, but note that guidance will vary since there is an active user session.

Example query-event notification

2.47.8 Notifications and Errors

If a server encounters errors while sending a notification, 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 of the subscription to error. If the error would be useful to a client (e.g., notification failed because the destination SSL certificate expired), servers SHOULD track errors and provide details to the client. If a notification retry attempt 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 server errors, a server SHOULD NOT allow clients to add errors.

2.47.8.1 Detecting Delivery Errors

One role of the SubscriptionStatus resource is to aid clients (subscribers) in error detection. Included are two classes of errors and how they can be found. Please note that this is not intended to serve as a comprehensive list of errors and their resolutions.

There are several mechanisms available to subscribers in order to understand the current state of notification delivery. Below are some example error scenarios with details about how a subscriber can detect the problem state.

2.47.8.1.1 Skipped Event

The diagram below shows how a subscriber can use the SubscriptionStatus.eventsSinceSubscriptionStart element on received notifications to determine that an event has been missed.

In the above sequence, the subscriber tracks the eventsSinceSubscriptionStart of each received notification (per Subscription). When the subscriber received event 23, the subscriber was aware that the last notification it received was a single notification for event 21. The subscriber then waited an amount of time to ensure that event 22 was indeed missing (and not, for example, still being processed) and started a recovery process. The recovery process itself will vary by subscriber, but should be a well-understood method for recovering in the event of errors.

2.47.8.1.2 Broken Communication

The diagram below show how a subscriber can use the Subscription.heartbeatPeriod to determine errors which prevent notifications from reaching the endpoint.

In the above sequence, the subscriber is aware that the heartbeatPeriod has elapsed for a subscription without receiving any notifications. The subscriber then asks the server for the $status of the subscription, and seeing an error, begins a recovery process. As in the previous scenario, the recovery process itself will vary by subscriber, but should be a well-understood method for recovering in the event of errors.