FHIR Chat · fhircast-docs / Issue #341 How can an application signal ... · fhircast-github

Stream: fhircast-github

Topic: fhircast-docs / Issue #341 How can an application signal ...

Github Notifications (FHIRcast) (Nov 09 2020 at 13:20):

bvdh opened Issue #341:

When an application cannot follow a context change event, it will respond with a sync-error. This will notify the other applications that they are no longer in sync.
When the application has resolved the issue - how does it signal that context can be changed? Does it wait for a resend of the -open/-close event or can it actively signal this?

Github Notifications (FHIRcast) (Nov 11 2020 at 22:01):

isaacvetter commented on Issue #341:

There is no way to currently actively signal the ending of a synchronization failure. It's a good idea.

What would you name such an event? I suppose it would be broadcasted to systems that subscribed to it?

Github Notifications (FHIRcast) (Nov 25 2020 at 13:42):

bvdh commented on Issue #341:

Some thoughts.

A sync-error means that one or or more applications are not in sync - did not follow the event indicated by the event-id.
Re-establishing sync, means that all applications are in sync again.

Root causes of sync-errors are:
1 application refuses change
2 an error in the application makes it impossible to process the change.
3 network error when sending the event
4 application has closed and did not unsubscribe

The only mechanism in the current specification is that the sender of the original spec, will resend the event after a short time.

Sync can only be re-established when the "network" is sound again - all application can receive events and are present. Topic 3 and 4 will be automatically handled as websockets will be closed and the application needs to resubscribe.

2 should be handled by the hub - if an error occurs regularly, the hub should unsubscribe it. Which will happen anyway after the timeout.

That leaves 1. The application could "withdraw" a syncerror with a syncrestored message. This could be a trigger to the hub to resend the original event (only when it is still the current one).
The advantage of this approach is that no .write authorization is required for the application that sends the syncrestored message. Note that the resending of the Patient-open by original and hub are still valid options also in this situation.

Conclusion:

• hubs SHALL resend an event that causes a sync-error, unless issue has been resolved by newer events.
• applications SHOULD resent an event that causes a sync-error
• applications SHOULD send a syncrestored event when the sync-error cause has been restored. This will trigger the hub to resent the original event (when relevant).

Would this work>

Github Notifications (FHIRcast) (Nov 25 2020 at 17:09):

gkustas commented on Issue #341:

I just left a comment in #311 regarding syncerror. My scenario falls into your second root causes @bvdh - an error in the application (PowerScribe) that made it impossible to process the change. How would your proposal work in this situation?

Like I said in the other thread, the end user sees the original error, and hopefully can rectify the error. In our case, the user will choose the appropriate study (accession from the proper RIS site) from the PowerScribe worklist, re-open the report causing another DiagnosticReport-open, and everyone would be back in sync again.

Or do you see other scenarios where the syncerror is used effectively?

Github Notifications (FHIRcast) (Nov 26 2020 at 08:12):

bvdh commented on Issue #341:

Sync-error will also be effective in indicating any of the other scenario's and can be used as a trigger to provide visual feedback to the user that sync is lost.
I think your scenario is good example of where an application due to a reason outside the scope of networking etc. refuses a context-change. I think that my solution will cover this.
Are we in sufficient agreement to move this into the spec (STU3 or STU2?).

Last updated: Apr 12 2022 at 19:14 UTC