Stream: fhircast-github

Topic: fhircast-docs / issue #311 syncerror

Github Notifications (FHIRcast) (May 14 2020 at 19:43):

isaacvetter opened Issue #311:

Especially for headless medical devices engaged in a FHIRcast session, it may be important for a subscriber to know the originating app of a syncerror event.

Could the syncerror event include some identifier of the app that caused the error (maybe client id?) such that a sufficiently sophisticated subscriber could attempt to evaluate the impact of a syncerror?

Github Notifications (FHIRcast) (May 27 2020 at 16:00):

gkustas commented on Issue #311:

@isaacvetter, @wmaethner -
I'm getting to the "syncerror" part of this, but just a little background first...
As an alternative to creating a "smart Hub" that provides the current topic session context on demand, we created two new events: DiagnosticReport-get and DiagnosticReport-set. The get is sent by a client wishing to know the current context (because perhaps it joined the party late or crashed). All other subscribers receive it and optionally respond to it with a DiagnosticReport-set. When subscribers receive the set message, they may find that the context is different from what they believe it to be. Hence, the syncerror is set.

I was going to implement this and realized that the syncerror is missing a few things to make it useful. Like you said, we should probably have client ids, and possibly names (that would be in the OAuth2 records for the client). But also, the syncerror doesn't have any place for structured error info. It's just a string. It would be useful to know who sent the syncerror, and WHY it sent it. Missing an ImagingStudy? Wrong accession number?

I'd love to get together with you guys and talk about the big picture some time. I'm hoping we can continue to keep the Hub "agnostic", but we're getting a lot of flak from Siemens, who claims that others in the WG-20 are not happy either.

Github Notifications (FHIRcast) (May 28 2020 at 13:58):

gkustas edited a comment on Issue #311:

@isaacvetter, @wmaethner -
I'm getting to the "syncerror" part of this, but just a little background first...
As an alternative to creating a "smart Hub" that provides the current topic session context on demand, we created two new events: DiagnosticReport-get and DiagnosticReport-set. The get is sent by a client wishing to know the current context (because perhaps it joined the party late or crashed). All other subscribers receive it and optionally respond to it with a DiagnosticReport-set. When subscribers receive the set message, they may find that the context is different from what they believe it to be. Hence, the syncerror is set.

I was going to implement this and realized that the syncerror is missing a few things to make it useful. Like you said, we should probably have client ids, and possibly names (that would be in the OAuth2 records for the client). But also, the syncerror doesn't have any place for structured error info. It's just a string. It would be useful to know who sent the syncerror, and WHY it sent it. Missing an ImagingStudy? Wrong accession number?

Github Notifications (FHIRcast) (Nov 25 2020 at 10:45):

bvdh commented on Issue #311:

It would also be usefull for the end-user - it can tell what application/system to check in order to resolve the sync-error. Good idea.

Github Notifications (FHIRcast) (Nov 25 2020 at 16:54):

gkustas commented on Issue #311:

We've encountered situations that I guess would call for a syncerror. Example:

1. PACS client requests a DiagnosticReport-open with an ImagingStudy that has accession 12345
2. PowerScribe receives the event and attempts to create the report, but finds that there are more than one accessions with that number. This can occur in a multi-site (multiple RIS) environment since accession numbers are not globally unique.

In this situation, PowerScribe displays a dialog to the user and the request is ignored,

If we send a syncerror event, what would it achieve, other than letting the other clients now that one of the other clients isn't in sync. What then?

The reality is that there is only one person driving all the applications, and they can see what happened. In this case, I think the user might just open the correct accession from the PowerScribe worklist which would generate ANOTHER DiagnosticReport-open would would override the previous. Everyone would be in sync again.

I'm still struggling to see the usefulness of the syncerror event.

Github Notifications (FHIRcast) (May 19 2021 at 17:51):

bvdh commented on issue #311:

I've summarized the discussion during the connecthaton in the following text.

Sync-error topics from Connecthaton

This lists several topics that came up using the sync-error discussion during the connecthaton.

event.context.issue.severity in syncerror events

The specification does not clearly define the value to use for the severity field in a syncerror.

When the event is sent by the hub (the event cannot be delivered), the severity SHALL be set to fatal.

When the event is send by an application, the severity SHALL be set to warning.

The syncerror event definition is to be updated with this content.

Identify application causing sync error

When a syncerror event is sent. The application should receive human readible information on why the event has happened.

This information is to be included in the syncerror event.context.issue.diagnostic field. When the event is sent by an application, it can fill this with appropriate information.

When the event is sent by the hub, the source of the information is not clear. An application SHOULD include a short human readible application name in the subscribe call.

The hub should use this information or information from the authorization server to provide provide a event.context.issue.diagnostic field that describes what happened and what application caused it.

The resulting specification updates are:

1. Update the syncerror event to state that the event.context.issue.diagnostic is mandatory and SHALL contain human-readable information on why the event has happened. The information SHALL indicate the device that causes the syncerror.
2. The subscribe method will be extended with an optional field holding a short human-readable name for the applications that registered.
3. The hub SHOULD use the indicated application name or the name retrieved from the authorization server to describe the device in the diagnostic message.

Clarify how to recover from an syncerror

The current specification does not clearly specify how applications and the hub can recover from an error condition.

The following approach was decided by the connecthaton discussion.

1. Applications that send an context-change event that resulted in a syncerror should resent them after about 10 sec. The event will be resent using the id and timestamp of the original event (this prevents race conditions with context-change events send by other applications).
2. Applications shall be able to receive resends of the same event, even at a later point in time, and handle it appropriately (check time stamp later than last, check if it changes the context or restates it).

When the resent does not result in a syncerror, applications know the system is in sync again.

An application is considered to be part of the topic until it unsubscribes or when the subscription expires. Until that time, any event that occurs that can not be delivered or is not followed will result in a syncerror.

This results in the following proposed specification changes:

1. Update the send event section with: Applications that send and context event that results in a sync-error SHOULD resent it (same time stamp) after some time (10 sec) to restablish context sync.
2. Update the receive event section with: Applications SHALL be able to receive resends of the same event, even at a later point in time, and handle it appropriately (check time stamp later than last, check if it changes the context or restates it).
3. Update the subscription section with: An application is considered to be part of the topic until it unsubscribes or when the subscription expires. Until that time, any event that occurs that can not be delivered or is not followed SHALL result in a syncerror.

Indicate how what happens when a connection drops

The specification is unclear on what is the expected behavior of clients and hubs when the connection is dropped.

Related questions are:

• Does a connection drop result in a unsubscribe?
• In what way does client detect that a connection is dropped?

The following approach was agreed upon during the connecthaton.

A client will detect a connection is dropped for websocket connections when the connection is dropped. Webhook connections require some sort of heartbeat to detect a network drop.
FHIRcast will define an optional heartbeat event which will be send every 10 sec/an order of magitutde lower then the subscription timeout. The interval will indicated in the event.

The event is RECOMMENDED for clients and hubs.

Implementator feedback is requested for the need to support heartbeats for websockets.

Heartbeat event

The heartbeat event is sent regularly to indicate a channel is open.

The name of the event is: heartbeat

Workflow

This event SHALL be send at least every 10 second. or an order of magnitude lower than the subscription time-out.

Context

The context of the -monitor event described in the table below.

Key	Optionality	#	type	Description
period	REQUIRED	1	decimal	The resend period in seconds

The first field indicates the repeat interval. If an event is not received within this time period, the connection may be assumed to be lost.

Example

An example heartbeat event is indicated below.

{
  "timestamp":"2021-05-19T10:24:58.614989800Z",
  "id":"sdkasldkals;610101498614",
  "event":{
    "context":[
      { "key":"period",
        "decimal": "10"
      }
    ],
    "hub.topic":"Topic1",
    "hub.event":"heartbeat"
  }
}

Github Notifications (FHIRcast) (Sep 15 2021 at 21:05):

bvdh commented on issue #311:

The commit does not cover this issue, just part of it.

Github Notifications (FHIRcast) (Nov 11 2021 at 17:02):

isaacvetter closed issue #311:

Especially for headless medical devices engaged in a FHIRcast session, it may be important for a subscriber to know the originating app of a syncerror event.

Could the syncerror event include some identifier of the app that caused the error (maybe client id?) such that a sufficiently sophisticated subscriber could attempt to evaluate the impact of a syncerror?

Last updated: Apr 12 2022 at 19:14 UTC