Integrated Reporting Applications
1.0.0 - Trial-Implementation International flag

This page is part of the Integrated Reporting Applications (v1.0.0: Publication) based on FHIR v5.0.0. This is the current published version. For a full list of available versions, see the Directory of published versions

2:4.156 Notify Error [RAD-156]

2:4.156.1 Scope

This transaction is used to send error notifications when a Subscriber initially accepted an event and later failed to process it.

2:4.156.2 Actors Roles

Table 2:4.156.2-1: Actor Roles

Role Description Actor(s)
Subscriber Sends error notifications Image Display
Report Creator
Worklist Client
Evidence Creator
Stateless Evidence Creator
Watcher
Manager Accepts and processes notification Hub

2:4.156.3 Referenced Standards

FHIRcast: Request Context Change

FHIRcast: Sync error Event

2:4.156.4 Messages

SubscriberManagerNotify ErrorNotify Error Response

Figure 2:4.156.4-1: Interaction Diagram

2:4.156.4.1 Notify Error Message

The Subscriber sends an error event to the Manager indicating that it failed to process a notification.

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

2:4.156.4.1.1 Trigger Events

The Subscriber failed to successfully process an context event that the Subscriber initially accepted and responded with 202 Accepted.

2:4.156.4.1.2 Message Semantics

This message is a FHIRcast Request Context Change request. The Subscriber is the FHIRcast Subscriber. The Manager is the FHIRcast Hub.

Note: This message uses an infrastructure event SyncError which does not change the request context. However, FHIRcast uses the same HTTP method to communicate infrastructure events. The difference is in the event definition.

The event.context shall conform to SyncError Context.

Per FHIRcast, the issue[0].severity of the operationoutcome context will be set to warning.

If the Sender is resending this error event due to not receiving a response from the Manager for a prior request, then the Sender shall use the same event.id. If the Manager received the original request, this allows it to detect that it is a duplicate message.

If the Sender retries the request due to an error response from the Manager, then the Sender shall assign a new event.id to indicate that it is a new request.

2:4.156.4.1.3 Expected Actions

The Manager shall receive, validate and process the request. See 2:3.156.4.2.2 for error conditions.

2:4.156.4.2 Notify Error Response Message

2:4.156.4.2.1 Trigger Events

The Manager finished processing the Notify Error request.

2:4.156.4.2.2 Message Semantics

This message is a FHIRcast Request Context Change response. The Subscriber is the FHIRcast Subscriber. The Manager is the FHIRcast Hub.

The Manager shall return 400 Bad Request error:

  • if timestamp, id or event are not set
  • if event.context does not include operationoutcome
  • if the context does not conform to the SyncError Context
  • if event.hub.topic is not a known session

The Manager may return other applicable HTTP error status codes.

2:4.156.4.2.3 Expected Actions

If the response is an error, then the Subscriber may consider retrying the request.

2:4.156.5 Security Considerations

See IRA Security Considerations.

2:4.156.5.1 Security Audit Considerations

This transaction is not associated with an ATNA Trigger Event.