FHIR Chat · fhircast-docs / Issue #99 May 2019 Ballot Comment: Do oth... · fhircast-github

Stream: fhircast-github

Topic: fhircast-docs / Issue #99 May 2019 Ballot Comment: Do oth...


view this post on Zulip Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):

hl7-fhircast-bot opened Issue #99

## May 2019 Ballot Comment: Do other susbcribers need to know the identity of the originator of a broadcasted sync-error notification?

Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Event Notification Errors
Url:
Type: A-Q Correction

Summary: Do other susbcribers need to know the identity of the originator of a broadcasted sync-error notification?

Comment: If a Hub forwards a sync-error event to other subscribers, how do the other subscribers recognize which system has the sync-error? E.g. EHR driving, PACS, dictation and reporting systems subscribing. The dictation system sends the EHR Hub a sync-error notification, which is then broadcast to the PACS and reporting subscribers. Does these subscribers need to know that it was the dictation system that errored? The Hub knows the identity of each subscriber due to the bearer token. To answer this question, we should determine what the other subscribers want to do with the notification.

Existing wording: The Hub MAY use these events to track synchronization state and MAY also forward these events to other subscribers of the same topic.


_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._

view this post on Zulip Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):

hl7-fhircast-bot labeled Issue #99

## May 2019 Ballot Comment: Do other susbcribers need to know the identity of the originator of a broadcasted sync-error notification?

Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Event Notification Errors
Url:
Type: A-Q Correction

Summary: Do other susbcribers need to know the identity of the originator of a broadcasted sync-error notification?

Comment: If a Hub forwards a sync-error event to other subscribers, how do the other subscribers recognize which system has the sync-error? E.g. EHR driving, PACS, dictation and reporting systems subscribing. The dictation system sends the EHR Hub a sync-error notification, which is then broadcast to the PACS and reporting subscribers. Does these subscribers need to know that it was the dictation system that errored? The Hub knows the identity of each subscriber due to the bearer token. To answer this question, we should determine what the other subscribers want to do with the notification.

Existing wording: The Hub MAY use these events to track synchronization state and MAY also forward these events to other subscribers of the same topic.


_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._

view this post on Zulip Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):

hl7-fhircast-bot edited Issue #99

## May 2019 Ballot Comment: Do other susbcribers need to know the identity of the originator of a broadcasted sync-error notification?

Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Event Notification Errors
Url:
Type: A-Q Correction

Summary: Do other susbcribers need to know the identity of the originator of a broadcasted sync-error notification?

Comment: If a Hub forwards a sync-error event to other subscribers, how do the other subscribers recognize which system has the sync-error? E.g. EHR driving, PACS, dictation and reporting systems subscribing. The dictation system sends the EHR Hub a sync-error notification, which is then broadcast to the PACS and reporting subscribers. Does these subscribers need to know that it was the dictation system that errored? The Hub knows the identity of each subscriber due to the bearer token. To answer this question, we should determine what the other subscribers want to do with the notification.

Existing wording: The Hub MAY use these events to track synchronization state and MAY also forward these events to other subscribers of the same topic.


_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._

view this post on Zulip Github Notifications (FHIRcast) (May 23 2019 at 14:11):

wmaethner labeled Issue #99:

## May 2019 Ballot Comment: Do other susbcribers need to know the identity of the originator of a broadcasted sync-error notification?

Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Event Notification Errors
Url:
Type: A-Q Correction

Summary: Do other susbcribers need to know the identity of the originator of a broadcasted sync-error notification?

Comment: If a Hub forwards a sync-error event to other subscribers, how do the other subscribers recognize which system has the sync-error? E.g. EHR driving, PACS, dictation and reporting systems subscribing. The dictation system sends the EHR Hub a sync-error notification, which is then broadcast to the PACS and reporting subscribers. Does these subscribers need to know that it was the dictation system that errored? The Hub knows the identity of each subscriber due to the bearer token. To answer this question, we should determine what the other subscribers want to do with the notification.

Existing wording: The Hub MAY use these events to track synchronization state and MAY also forward these events to other subscribers of the same topic.


_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._

view this post on Zulip Github Notifications (FHIRcast) (May 23 2019 at 14:12):

wmaethner commented on Issue #99:

Proposed resolution:
Question answered

  • No, other subscribers do not need to know the identity of the application in which the sync-error occurred.
  • Would be nice, but not required, to further explain the reasoning behind this.

view this post on Zulip Github Notifications (FHIRcast) (May 23 2019 at 14:25):

NiklasSvenzen commented on Issue #99:

What is important is to be able to notify an end user that there are applications out of sync. Not necessarily all the intricate details of which application or why. Most applications dealing with patients are required to have a patient banner, so it is easy for an end user to figure out which application is out of sync, the important thing is to know when to look.

view this post on Zulip Github Notifications (FHIRcast) (Jul 15 2019 at 22:07):

isaacvetter commented on Issue #99:

Proposed Resolution: Question Answered.

view this post on Zulip Github Notifications (FHIRcast) (Jul 24 2019 at 14:06):

wmaethner commented on Issue #99:

## :landline: II Working Group Vote (7-24-2019)
Block vote 3

Ricardo Quintano Neira moved the following disposition, seconded by @isaacvetter

Disposition: Persuasive
Disposition Comment: Will fix as described in the issue comments or by the commenter

:+1: For: 11
:expressionless: Abstain: 1
:-1: Against: 0

:tada: The motion passed! :tada:

view this post on Zulip Github Notifications (FHIRcast) (Jul 24 2019 at 14:06):

wmaethner labeled Issue #99:

## May 2019 Ballot Comment: Do other susbcribers need to know the identity of the originator of a broadcasted sync-error notification?

Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Event Notification Errors
Url:
Type: A-Q Correction

Summary: Do other susbcribers need to know the identity of the originator of a broadcasted sync-error notification?

Comment: If a Hub forwards a sync-error event to other subscribers, how do the other subscribers recognize which system has the sync-error? E.g. EHR driving, PACS, dictation and reporting systems subscribing. The dictation system sends the EHR Hub a sync-error notification, which is then broadcast to the PACS and reporting subscribers. Does these subscribers need to know that it was the dictation system that errored? The Hub knows the identity of each subscriber due to the bearer token. To answer this question, we should determine what the other subscribers want to do with the notification.

Existing wording: The Hub MAY use these events to track synchronization state and MAY also forward these events to other subscribers of the same topic.


_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._

view this post on Zulip Github Notifications (FHIRcast) (Sep 06 2019 at 19:21):

isaacvetter commented on Issue #99:

Closing as question answered.

view this post on Zulip Github Notifications (FHIRcast) (Sep 06 2019 at 19:21):

isaacvetter closed Issue #99:

May 2019 Ballot Comment: Do other susbcribers need to know the identity of the originator of a broadcasted sync-error notification?

Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Event Notification Errors
Url:
Type: A-Q Correction

Summary: Do other susbcribers need to know the identity of the originator of a broadcasted sync-error notification?

Comment: If a Hub forwards a sync-error event to other subscribers, how do the other subscribers recognize which system has the sync-error? E.g. EHR driving, PACS, dictation and reporting systems subscribing. The dictation system sends the EHR Hub a sync-error notification, which is then broadcast to the PACS and reporting subscribers. Does these subscribers need to know that it was the dictation system that errored? The Hub knows the identity of each subscriber due to the bearer token. To answer this question, we should determine what the other subscribers want to do with the notification.

Existing wording: The Hub MAY use these events to track synchronization state and MAY also forward these events to other subscribers of the same topic.


_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._


Last updated: Apr 12 2022 at 19:14 UTC