Release 4B

This page is part of the FHIR Specification (v4.3.0: R4B - STU). The current version which supercedes this version is 5.0.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 GroupMaturity Level: 0 DraftSecurity 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 topic-based model of Subscriptions (Publish / Subscribe pattern).

The SubscriptionStatus resource is used to convey information about the current state of a Subscription and the contents of a notification. 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 the current notification (e.g., notification type, the events in this notification)

2.47.2 Boundaries and Relationships

The SubscriptionStatus resource is used in topic-based FHIR Subscriptions. This resource is designed only to be used to convey state information about a subscription and notification 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.

2.47.4 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. SubscriptionStatus DDomainResourceStatus information about a Subscription provided during event notification
+ Rule: events listed in event notifications
Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... status Σ0..1coderequested | active | error | off | entered-in-error
SubscriptionStatusCodes (Required)
... type ?!Σ1..1codehandshake | heartbeat | event-notification | query-status | query-event
SubscriptionNotificationType (Required)
... eventsSinceSubscriptionStart Σ0..1stringEvents since the Subscription was created
.... eventNumber 1..1stringEvent number
.... timestamp 0..1instantThe instant this event occurred
.... focus 0..1Reference(Any)The focus of this event
.... additionalContext 0..*Reference(Any)Additional context for this event
... subscription Σ1..1Reference(Subscription)Reference to the Subscription responsible for this notification
... topic Σ0..1canonical(SubscriptionTopic)Reference to the SubscriptionTopic this notification relates to
... error Σ0..*CodeableConceptList of errors on the subscription
Subscription Error Codes (Example)

doco Documentation for this format

UML Diagram (Legend)

SubscriptionStatus (DomainResource)The status of the subscription, which marks the server state for managing the subscriptionstatus : code [0..1] « null (Strength=Required)SubscriptionStatusCodes! »The type of event being conveyed with this notificaiton (this element modifies the meaning of other elements)type : code [1..1] « null (Strength=Required)SubscriptionNotificationType! »The total number of actual events which have been generated since the Subscription was created (inclusive of this notification) - regardless of how many have been successfully communicated. This number is NOT incremented for handshake and heartbeat notificationseventsSinceSubscriptionStart : string [0..1]The reference to the Subscription which generated this notificationsubscription : Reference [1..1] « Subscription »The reference to the SubscriptionTopic for the Subscription which generated this notificationtopic : canonical [0..1] « SubscriptionTopic »A record of errors that occurred when the server processed a notificationerror : CodeableConcept [0..*] « null (Strength=Example)SubscriptionErrorCodes?? »NotificationEventThe sequential number of this event in this subscription context. Note that this value is a 64-bit integer value, encoded as a stringeventNumber : string [1..1]The actual time this event occured on the servertimestamp : instant [0..1]The focus of this event. While this will usually be a reference to the focus resource of the event, it MAY contain a reference to a non-FHIR objectfocus : Reference [0..1] « Any »Additional context information for this event. Generally, this will contain references to additional resources included with the event (e.g., the Patient relevant to an Encounter), however it MAY refer to non-FHIR objectsadditionalContext : Reference [0..*] « Any »Detailed information about events relevant to this subscription notificationnotificationEvent[0..*]

XML Template

<SubscriptionStatus xmlns="http://hl7.org/fhir"> doco
 <!-- 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 -->
 <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>

Turtle Template

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


[ 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.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 R4

This resource did not exist in Release 3

This analysis is available as XML or JSON.

Conversions between R3 and R4

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. SubscriptionStatus DDomainResourceStatus information about a Subscription provided during event notification
+ Rule: events listed in event notifications
Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... status Σ0..1coderequested | active | error | off | entered-in-error
SubscriptionStatusCodes (Required)
... type ?!Σ1..1codehandshake | heartbeat | event-notification | query-status | query-event
SubscriptionNotificationType (Required)
... eventsSinceSubscriptionStart Σ0..1stringEvents since the Subscription was created
.... eventNumber 1..1stringEvent number
.... timestamp 0..1instantThe instant this event occurred
.... focus 0..1Reference(Any)The focus of this event
.... additionalContext 0..*Reference(Any)Additional context for this event
... subscription Σ1..1Reference(Subscription)Reference to the Subscription responsible for this notification
... topic Σ0..1canonical(SubscriptionTopic)Reference to the SubscriptionTopic this notification relates to
... error Σ0..*CodeableConceptList of errors on the subscription
Subscription Error Codes (Example)

doco Documentation for this format

UML Diagram (Legend)

SubscriptionStatus (DomainResource)The status of the subscription, which marks the server state for managing the subscriptionstatus : code [0..1] « null (Strength=Required)SubscriptionStatusCodes! »The type of event being conveyed with this notificaiton (this element modifies the meaning of other elements)type : code [1..1] « null (Strength=Required)SubscriptionNotificationType! »The total number of actual events which have been generated since the Subscription was created (inclusive of this notification) - regardless of how many have been successfully communicated. This number is NOT incremented for handshake and heartbeat notificationseventsSinceSubscriptionStart : string [0..1]The reference to the Subscription which generated this notificationsubscription : Reference [1..1] « Subscription »The reference to the SubscriptionTopic for the Subscription which generated this notificationtopic : canonical [0..1] « SubscriptionTopic »A record of errors that occurred when the server processed a notificationerror : CodeableConcept [0..*] « null (Strength=Example)SubscriptionErrorCodes?? »NotificationEventThe sequential number of this event in this subscription context. Note that this value is a 64-bit integer value, encoded as a stringeventNumber : string [1..1]The actual time this event occured on the servertimestamp : instant [0..1]The focus of this event. While this will usually be a reference to the focus resource of the event, it MAY contain a reference to a non-FHIR objectfocus : Reference [0..1] « Any »Additional context information for this event. Generally, this will contain references to additional resources included with the event (e.g., the Patient relevant to an Encounter), however it MAY refer to non-FHIR objectsadditionalContext : Reference [0..*] « Any »Detailed information about events relevant to this subscription notificationnotificationEvent[0..*]

XML Template

<SubscriptionStatus xmlns="http://hl7.org/fhir"> doco
 <!-- 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 -->
 <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>

Turtle Template

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


[ 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.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 4

This resource did not exist in Release 3

This analysis is available as XML or JSON.

Conversions between R3 and R4

 

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

PathDefinitionTypeReference
SubscriptionStatus.status RequiredSubscriptionStatusCodes
SubscriptionStatus.type RequiredSubscriptionNotificationType
SubscriptionStatus.error ExampleSubscriptionErrorCodes

2.47.4.2 Constraints

idLevelLocationDescriptionExpression
sst-1Rule (base)events listed in event notificationstype = 'event-notification' implies (notificationEvent.exists() and notificationEvent.first().exists())

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

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.

ElementOptionalityNotes
SubscriptionStatus.statusRecommendedCurrent status of the relevant subscription (e.g., active).
SubscriptionStatus.typeRequiredSHALL be event-notification
SubscriptionStatus.eventsSinceSubscriptionStartRequiredServers SHALL 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.notificationEventRequiredFor notifications that include events, this element SHALL be present. Details about specific elements within this structure are included in this table.
SubscriptionStatus.notificationEvent.eventNumberRequiredThis element is mandatory if a notificationEvent is present.
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:
  • empty: SHALL NOT be present
  • id-only: SHALL be present
  • full-resource: SHALL be present
SubscriptionStatus.notificationEvent.additionalContextSpecialLinks 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:
  • empty: SHALL NOT be present
  • id-only: SHOULD be present
  • full-resource: SHOULD be present
SubscriptionStatus.topicOptionalSee Content and PHI.

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

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.eventNumberSpecialThis element is mandatory if a notificationEvent is present.
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:
  • empty: SHALL NOT be present
  • id-only: SHALL be present if a notificationEvent is included
  • full-resource: SHALL be present if a notificationEvent is present
SubscriptionStatus.notificationEvent.additionalContextSpecialLinks 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:
  • empty: SHALL NOT be present
  • id-only: SHOULD be present if a notificationEvent is present
  • full-resource: SHOULD be present if a notificationEvent is present
SubscriptionStatus.topicOptionalSee 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.

2.47.7.3 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 one heartbeat per interval on the accepted subscription.

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.
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.eventNumberSpecialThis element is mandatory if a notificationEvent is present.
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:
  • empty: SHALL NOT be present
  • id-only: SHALL be present if a notificationEvent is included
  • full-resource: SHALL be present if a notificationEvent is present
SubscriptionStatus.notificationEvent.additionalContextSpecialLinks 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:
  • empty: SHALL NOT be present
  • id-only: SHOULD be present if a notificationEvent is present
  • full-resource: SHOULD be present if a notificationEvent is present
SubscriptionStatus.topicOptionalSee Content and PHI.

2.47.7.4 Query Status

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.eventsSinceSubscriptionStartRequiredThis 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.notificationEventProhibitedA query-status notification SHALL NOT contain any event information.
SubscriptionStatus.topicRecommendedSee Content and PHI, but note that guidance will vary since there is an active user session.

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.

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.
Note: this value SHALL NOT be incremented by sending a query-event bundle.
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.eventNumberRequiredThis element is mandatory if a notificationEvent is present.
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:
  • empty: SHALL NOT be present
  • id-only: SHALL be present
  • full-resource: SHALL be present
SubscriptionStatus.notificationEvent.additionalContextSpecialLinks 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:
  • empty: SHALL NOT be present
  • id-only: SHOULD be present
  • full-resource: SHOULD be present
SubscriptionStatus.topicRecommendedSee Content and PHI, but note that guidance will vary since there is an active user session.

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

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 Missing Event

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

Diagram showing a missed-event detection and recovery workflow
Diagram showing a missed-event detection and recovery workflow

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 a subscription heartbeat period to determine errors which prevent notifications from reaching the endpoint.

Diagram showing broken communication detection and recovery workflow
Diagram showing broken communication detection and recovery workflow

In the above sequence, the subscriber is aware that the heartbeatPeriod has elapsed for a subscription without receiving any notifications. .

2.47.8.1.3 Recovering from Errors

Clients are responsible for devising an appropriate method for recovering from errors. Often, this process will include a series or batch of requests that allow a client to know the current state or a request to an $events operation when available. For example, an application may need to query all relevant resources for a patient in order to ensure nothing has been missed. Once an application has returned to a functional state, it should request the subscription is reactivated by updating the status to either requested or active as appropriate.

2.47.8.1.4 Using the $events operation

Servers MAY choose to support the $events operation defined on the Subscription resource. The $events operation allows clients to request events which have occurred in the past. Servers which implement the operation MAY use implementation-specific criteria to restrict availability of events (e.g., most recent 10 events, events within the past 30 days, etc.).

During a recovery process, clients MAY try to retrieve missing events via the $events operation, which should allow processing to continue as normal.