Figure 2:4.154.4-1: Interaction Diagram

2:4.154.4.1 Notification Message

The Manager sends the received notification events to Subscribers that listed this event type in their subscription.

The Manager shall support sending such messages to more than one Subscriber. The Subscriber shall support handling such messages from more than one Manager.

The Manager shall send a separate Notification message to each Subscriber.

2:4.154.4.1.1 Trigger Events

The Manager accepts a notification event request (e.g. context events, syncerror events or other infrastructure events such as heartbeat events) and this Subscriber has listed this event type in its subscription.

2:4.154.4.1.2 Message Semantics

This message is a FHIRcast Event Notification Request request. The Manager is the FHIRcast Hub. The Subscriber is the FHIRcast Subscriber.

The Manager shall support the additional requirements regarding version id defined in FHIRcast content sharing.

2:4.154.4.1.3 Expected Actions

The Subscriber may validate the received event according to its business logic. If the Subscriber rejects the event, then it shall notify the Manager about the error.

The Subscriber shall handle events [FHIR resource]-open | update | select | close that it supports. Handling requirements for some general types of events are described below. Profile specific event handling requirements are defined in the Actor Description for each actor per profile.

The Subscriber shall support content sharing.

Note: The Subscriber may handle the event synchronously. The Subscriber may also handle the event asynchronously by accepting the event initially (i.e., returning 202 Accepted) and processing it later.

2:4.154.4.1.3.1 Handling open events

Upon receiving a [FHIR resource]-open event, the Subscriber will open the corresponding event.context according to its business logic. The semantics of the open event may be further described in the corresponding ‘open request’ transaction.

Note: [FHIR resource]-open events occur when a context is initially created and when it is re-opened. Subscriber event handling may differ for these two cases.

The Subscriber shall keep track of the context.versionId in the local context.

2:4.154.4.1.3.2 Handling update events

Upon receiving a [FHIR resource]-update event, the Subscriber:

• Shall validate if the context.priorVersionId in the event matches the current version ID in the local context.
  • If true, the Subscriber shall handle the update event according to its business logic.
  • If not, this means the Subscriber missed one or more prior events. In this case, the Subscriber is responsible for subsequently retrieving the current context and applying the retrieved context according to its business logic.
• Shall update the current version ID in the local context to match the context.versionId from the event, even if its business logic requires no specific processing.
• For contents of interest that are not inline in the [FHIR resource]-update event and referenced by a relative path, the Subscriber shall retrieve the content based on the entry.fullurl.
• May process a subset of updates specified in the updates context key according to its business logic.
  • For relevant updates, the Subscriber shall stay synchronized with the report context
• May ignore updates associated to an anchor context that the Subscriber is unaware of

2:4.154.4.1.3.3 Handling select events

Upon receiving a [FHIR resource]-select event, the Subscriber:

• Shall unselect all previously selected contents
• Shall select all applicable resources in the local context according to the referenced resources in the event
• Shell be capable of using applicable selected resources in subsequent user commands according to its business logic.
• Shall ignore any resources referenced in the event that are not known to the Subscriber

2:4.154.4.1.3.4 Handling close events

Upon receiving a [FHIR resource]-close event, the Subscriber shall close the referenced context and all associated contents. This typically involves deleting it from its local context.

2:4.154.4.2 Notification Response Message

2:4.154.4.2.1 Trigger Events

The Subscriber processes the Notification Message.

2:4.154.4.2.2 Message Semantics

The message is a FHIRcast Event Notification Response request. The Subscriber is a FHIRcast Subscriber. The Manager is a FHIRcast Hub.

The Subscriber shall send a confirmation message back to the Manager using the established websocket connection.

2:4.154.4.2.3 Expected Actions

If the Manager receives an error confirmation message (i.e., status 4xx or 5xx) from at least one of the Subscribers, then the Manager shall send a syncerror event using the Generate SyncError Event (RAD-155) transaction to all subscribers that subscribed to the syncerror event.

The Manager shall not change the current context in the session even if it receives an error confirmation message.

Note: The Manager sets the current context as a result of processing a [FHIR resource]-open event. Whether or not one or more of the Subscribers failed to apply the context change does not affect the context managed by the Manager.

2:4.154.5 Security Considerations

See IRA Security Considerations.

2:4.154.5.1 Security Audit Considerations

This transaction is not associated with an ATNA Trigger Event.