Stream: fhircast-github
Topic: fhircast-docs / Issue #156 May 2019 Ballot Comment: Is th...
Github Notifications (FHIRcast) (Apr 30 2019 at 19:52):
hl7-fhircast-bot opened Issue #156
## May 2019 Ballot Comment: Is the switch events needed?
Submitted by Ricardo Quintano Neira on behalf of @bvdh
Chapter/section: Event Catalog
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: EnhancementSummary: Is the switch events needed?
Comment: Issue/comment imported from https://github.com/HL7/fhircast-docs/issues/71
"From an EMR/UI perspective, open, switch and close patient are understandable. From an application subscribed to FHIRCast events the difference between open and switch is small.
On open, the new patient/study will be the main one.
On switch, the existing patient/study will be the main one.
On close, the patient/study is no longer relevant.Switch has the same connotation as open without a close of the current patient, forcing the application to listen to switch as well as open. The action it would take would be the same.
From that point of view I wonder what the additional value of switch is and suggest to remove patient-switch and study-switch."
_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 #156
## May 2019 Ballot Comment: Is the switch events needed?
Submitted by Ricardo Quintano Neira on behalf of @bvdh
Chapter/section: Event Catalog
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: EnhancementSummary: Is the switch events needed?
Comment: Issue/comment imported from https://github.com/HL7/fhircast-docs/issues/71
"From an EMR/UI perspective, open, switch and close patient are understandable. From an application subscribed to FHIRCast events the difference between open and switch is small.
On open, the new patient/study will be the main one.
On switch, the existing patient/study will be the main one.
On close, the patient/study is no longer relevant.Switch has the same connotation as open without a close of the current patient, forcing the application to listen to switch as well as open. The action it would take would be the same.
From that point of view I wonder what the additional value of switch is and suggest to remove patient-switch and study-switch."
_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 #156
## May 2019 Ballot Comment: Is the switch events needed?
Submitted by Ricardo Quintano Neira on behalf of @bvdh
Chapter/section: Event Catalog
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: EnhancementSummary: Is the switch events needed?
Comment: Issue/comment imported from https://github.com/HL7/fhircast-docs/issues/71
"From an EMR/UI perspective, open, switch and close patient are understandable. From an application subscribed to FHIRCast events the difference between open and switch is small.
On open, the new patient/study will be the main one.
On switch, the existing patient/study will be the main one.
On close, the patient/study is no longer relevant.Switch has the same connotation as open without a close of the current patient, forcing the application to listen to switch as well as open. The action it would take would be the same.
From that point of view I wonder what the additional value of switch is and suggest to remove patient-switch and study-switch."
_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 #156
## May 2019 Ballot Comment: Is the switch events needed?
Submitted by Ricardo Quintano Neira on behalf of @bvdh
Chapter/section: Event Catalog
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: EnhancementSummary: Is the switch events needed?
Comment: Issue/comment imported from https://github.com/HL7/fhircast-docs/issues/71
"From an EMR/UI perspective, open, switch and close patient are understandable. From an application subscribed to FHIRCast events the difference between open and switch is small.
On open, the new patient/study will be the main one.
On switch, the existing patient/study will be the main one.
On close, the patient/study is no longer relevant.Switch has the same connotation as open without a close of the current patient, forcing the application to listen to switch as well as open. The action it would take would be the same.
From that point of view I wonder what the additional value of switch is and suggest to remove patient-switch and study-switch."
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 21:11):
isaacvetter labeled Issue #156
## May 2019 Ballot Comment: Is the switch events needed?
Submitted by Ricardo Quintano Neira on behalf of @bvdh
Chapter/section: Event Catalog
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: EnhancementSummary: Is the switch events needed?
Comment: Issue/comment imported from https://github.com/HL7/fhircast-docs/issues/71
"From an EMR/UI perspective, open, switch and close patient are understandable. From an application subscribed to FHIRCast events the difference between open and switch is small.
On open, the new patient/study will be the main one.
On switch, the existing patient/study will be the main one.
On close, the patient/study is no longer relevant.Switch has the same connotation as open without a close of the current patient, forcing the application to listen to switch as well as open. The action it would take would be the same.
From that point of view I wonder what the additional value of switch is and suggest to remove patient-switch and study-switch."
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 06 2019 at 21:21):
isaacvetter commented on Issue #156
Proposed resolution: Persuasive with Mod
We will remove
Github Notifications (FHIRcast) (May 06 2019 at 21:30):
isaacvetter edited a comment on Issue #156
In conversation with @NiklasSvenzen , @wmaethner, @RicardoQuintano, we decided to make a more structural change to enable community-submitted events and to allow events to mature independently of the base spec.
Proposed resolution: Persuasive with Mod
We will remove the switch events, but also move the Event Catalog out of the base FHIRcast specification. We will also define a documentation template and process to mature a given hook or set of hooks. (For inspiration, we'll look at the FHIR Maturity Model and CDS Hooks Maturity Model).
Github Notifications (FHIRcast) (May 08 2019 at 14:29):
isaacvetter commented on Issue #156
Proposed resolution: Persuasive with Mod
We will remove the switch events, but also move the Event Catalog out of the base FHIRcast specification. We will also define a documentation template and process and syntax to define and mature a given event or set of events considering how FHIR resources should be naturally included within event syntax.
Mover: Ioana, Niklas
Affirmative/Abstention/Negative: 14-0-0
Github Notifications (FHIRcast) (May 08 2019 at 14:29):
NiklasSvenzen labeled Issue #156
## May 2019 Ballot Comment: Is the switch events needed?
Submitted by Ricardo Quintano Neira on behalf of @bvdh
Chapter/section: Event Catalog
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: EnhancementSummary: Is the switch events needed?
Comment: Issue/comment imported from https://github.com/HL7/fhircast-docs/issues/71
"From an EMR/UI perspective, open, switch and close patient are understandable. From an application subscribed to FHIRCast events the difference between open and switch is small.
On open, the new patient/study will be the main one.
On switch, the existing patient/study will be the main one.
On close, the patient/study is no longer relevant.Switch has the same connotation as open without a close of the current patient, forcing the application to listen to switch as well as open. The action it would take would be the same.
From that point of view I wonder what the additional value of switch is and suggest to remove patient-switch and study-switch."
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 08 2019 at 15:44):
isaacvetter edited a comment on Issue #156
## Montreal May 2019 Working Group Vote
@IoanaSingureanu moved the following disposition, seconded by @NiklasSvenzen
Disposition: Persuasive with Mod
Disposition Comment: We will remove the switch events, but also move the Event Catalog out of the base FHIRcast specification. We will also define a documentation template and process and syntax to define and mature a given event or set of events considering how FHIR resources should be naturally included within event syntax.:+1: For: 14
:expressionless: Abstain: 0
:-1: Against: 0:tada: The motion passed! :tada:
Github Notifications (FHIRcast) (Sep 11 2019 at 20:43):
wmaethner closed Issue #156:
May 2019 Ballot Comment: Is the switch events needed?
Submitted by Ricardo Quintano Neira on behalf of @bvdh
Chapter/section: Event Catalog
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: EnhancementSummary: Is the switch events needed?
Comment: Issue/comment imported from https://github.com/HL7/fhircast-docs/issues/71
"From an EMR/UI perspective, open, switch and close patient are understandable. From an application subscribed to FHIRCast events the difference between open and switch is small.
On open, the new patient/study will be the main one.
On switch, the existing patient/study will be the main one.
On close, the patient/study is no longer relevant.Switch has the same connotation as open without a close of the current patient, forcing the application to listen to switch as well as open. The action it would take would be the same.
From that point of view I wonder what the additional value of switch is and suggest to remove patient-switch and study-switch."
_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
