Stream: fhircast-github
Topic: fhircast-docs / Issue #128 May 2019 Ballot Comment: Inclu...
Github Notifications (FHIRcast) (Apr 30 2019 at 19:52):
hl7-fhircast-bot opened Issue #128
## May 2019 Ballot Comment: Include functionality to register/send new (prop) event types determined by the applications and not by the hub.
Submitted by Ricardo Quintano Neira on behalf of @bvdh
Chapter/section: Subscribing and Unsubscribingt
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: A-S EnhancementSummary: Include functionality to register/send new (prop) event types determined by the applications and not by the hub.
Comment: Include functionality to register a new event type in the hub.
One subscriber application may create a new event that can be understood by other applications. The hub does not need to know previously this event (i.e. event from the catalog).
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:52):
hl7-fhircast-bot labeled Issue #128
## May 2019 Ballot Comment: Include functionality to register/send new (prop) event types determined by the applications and not by the hub.
Submitted by Ricardo Quintano Neira on behalf of @bvdh
Chapter/section: Subscribing and Unsubscribingt
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: A-S EnhancementSummary: Include functionality to register/send new (prop) event types determined by the applications and not by the hub.
Comment: Include functionality to register a new event type in the hub.
One subscriber application may create a new event that can be understood by other applications. The hub does not need to know previously this event (i.e. event from the catalog).
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:52):
hl7-fhircast-bot edited Issue #128
## May 2019 Ballot Comment: Include functionality to register/send new (prop) event types determined by the applications and not by the hub.
Submitted by Ricardo Quintano Neira on behalf of @bvdh
Chapter/section: Subscribing and Unsubscribingt
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: A-S EnhancementSummary: Include functionality to register/send new (prop) event types determined by the applications and not by the hub.
Comment: Include functionality to register a new event type in the hub.
One subscriber application may create a new event that can be understood by other applications. The hub does not need to know previously this event (i.e. event from the catalog).
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 06 2019 at 22:40):
isaacvetter commented on Issue #128
During conversation at the Montreal, May 2019 working group meeting, @RicardoQuintano, @wmaethner, @NiklasSvenzen and myself talked through this issue.
It's a doozy, @bvdh! :octopus:
Proposed Resolution:
This is a really neat idea. It's pretty far outside of limited 1.0 scope. I'd like to set the status on this gh issue to deferred, but vote Not Persuasive.
Github Notifications (FHIRcast) (May 08 2019 at 14:59):
NiklasSvenzen labeled Issue #128
## May 2019 Ballot Comment: Include functionality to register/send new (prop) event types determined by the applications and not by the hub.
Submitted by Ricardo Quintano Neira on behalf of @bvdh
Chapter/section: Subscribing and Unsubscribingt
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: A-S EnhancementSummary: Include functionality to register/send new (prop) event types determined by the applications and not by the hub.
Comment: Include functionality to register a new event type in the hub.
One subscriber application may create a new event that can be understood by other applications. The hub does not need to know previously this event (i.e. event from the catalog).
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 21 2019 at 13:52):
wmaethner labeled Issue #128:
## May 2019 Ballot Comment: Include functionality to register/send new (prop) event types determined by the applications and not by the hub.
Submitted by Ricardo Quintano Neira on behalf of @bvdh
Chapter/section: Subscribing and Unsubscribingt
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: A-S EnhancementSummary: Include functionality to register/send new (prop) event types determined by the applications and not by the hub.
Comment: Include functionality to register a new event type in the hub.
One subscriber application may create a new event that can be understood by other applications. The hub does not need to know previously this event (i.e. event from the catalog).
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Jun 04 2019 at 14:06):
isaacvetter edited a comment on Issue #128:
During conversation at the Montreal, May 2019 working group meeting, @RicardoQuintano, @wmaethner, @NiklasSvenzen and myself talked through this issue.
It's a doozy, @bvdh! :octopus:
Proposed Resolution:
This is a really neat idea. It's pretty far outside of limited 1.0 scope. I'd like to set the status on this gh issue to deferred, but vote Consider for Future Use.
Github Notifications (FHIRcast) (Jun 05 2019 at 14:15):
wmaethner unlabeled Issue #128:
## May 2019 Ballot Comment: Include functionality to register/send new (prop) event types determined by the applications and not by the hub.
Submitted by Ricardo Quintano Neira on behalf of @bvdh
Chapter/section: Subscribing and Unsubscribingt
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: A-S EnhancementSummary: Include functionality to register/send new (prop) event types determined by the applications and not by the hub.
Comment: Include functionality to register a new event type in the hub.
One subscriber application may create a new event that can be understood by other applications. The hub does not need to know previously this event (i.e. event from the catalog).
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Jul 16 2019 at 13:23):
isaacvetter commented on Issue #128:
Proposed resolution: Persuasive with Mod
Proposed resolution comment: The creation of a FHIRcast event syntax as described in the proposed resolution to #108 achieves the goals described by @bvdh without the need to create event registration. The capability of a hub to relay events that it doesn't understand is a capability of the hub not addressed by the specification.
Github Notifications (FHIRcast) (Jul 17 2019 at 14:43):
isaacvetter commented on Issue #128:
## :telephone_receiver: II Working Group Vote (5-30-2019)
Meeting notes: https://confluence.hl7.org/display/IMIN/Teleconferences
@isaacvetter moved the following disposition, seconded by @NiklasSvenzen
Disposition: Persuasive with Mod
Disposition Comment: The creation of a FHIRcast event syntax as described in the proposed resolution to #108 achieves the goals described by @bvdh without the need to create event registration. The capability of a hub to relay events that it doesn't understand is a capability of the hub not addressed by the specification.:+1: For: 13
:expressionless: Abstain: 0
:-1: Against: 0:tada: The motion passed! :tada:
Github Notifications (FHIRcast) (Jul 17 2019 at 14:44):
wmaethner labeled Issue #128:
## May 2019 Ballot Comment: Include functionality to register/send new (prop) event types determined by the applications and not by the hub.
Submitted by Ricardo Quintano Neira on behalf of @bvdh
Chapter/section: Subscribing and Unsubscribingt
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: A-S EnhancementSummary: Include functionality to register/send new (prop) event types determined by the applications and not by the hub.
Comment: Include functionality to register a new event type in the hub.
One subscriber application may create a new event that can be understood by other applications. The hub does not need to know previously this event (i.e. event from the catalog).
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Sep 11 2019 at 20:45):
wmaethner commented on Issue #128:
Fixed as part of PR #276
Github Notifications (FHIRcast) (Sep 11 2019 at 20:45):
wmaethner closed Issue #128:
May 2019 Ballot Comment: Include functionality to register/send new (prop) event types determined by the applications and not by the hub.
Submitted by Ricardo Quintano Neira on behalf of @bvdh
Chapter/section: Subscribing and Unsubscribingt
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: A-S EnhancementSummary: Include functionality to register/send new (prop) event types determined by the applications and not by the hub.
Comment: Include functionality to register a new event type in the hub.
One subscriber application may create a new event that can be understood by other applications. The hub does not need to know previously this event (i.e. event from the catalog).
_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
