Stream: fhircast-github
Topic: fhircast-docs / Issue #71 Is the switch event needed?
Github Notifications (FHIRcast) (Feb 21 2019 at 09:19):
bvdh opened Issue #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.
Github Notifications (FHIRcast) (Mar 11 2019 at 17:43):
isaacvetter commented on Issue #71
Hey @bvdh ,
Great points. The list of events was informed by current state integrations. I agree with everything you say, above.
In production, applications and clinical workflow can:
1) Only ever have a single patient's record open at a time.
2) Support having multiple patients "open", but only ever one in focus.
3) Support having multiple patients in focus.
4) Support having no patients in focus.For scenario (2), how can we enable synchronization between two apps which are both capable of having multiple patients "open", but only ever one in focus?
For scenario (4), how can we enable synchronization where the one app has multiple patients "open", but the user moves to an activity with no patients in focus?
We could:
1) Drop the switch events now.
2) Move the event catalog out of the spec, so that it can mature indepdently.
3) Figure this out during the May connectathon and ballot resolution.Would you be willing to submit this as a ballot comment?
Isaac
Github Notifications (FHIRcast) (Mar 11 2019 at 18:35):
I'll file all open ticket here as a ballot topics.
Regarding this issue, based on the comments you provided, we might need to expand the events to reflect the state of the application. I understand that a patient/study can be open. Zero, one or more patients/studies can be in focus.
Maybe we should have the following events:
open-patient/open-study
close-patient/close-study
focus-change : lists the current patient/studies in focus.
The reason for the last event to be separate is that we can signal both states separately. The reason for providing a focus list instead of individual events is that it forces application to consider that fact that there can be more than one patient in focus.
Any thoughts?
Github Notifications (FHIRcast) (Apr 30 2019 at 21:13):
isaacvetter commented on Issue #71
duplicate of negative, ballot issue #102 156
Github Notifications (FHIRcast) (May 30 2019 at 02:41):
isaacvetter edited a comment on Issue #71:
duplicate of negative, ballot issue #102 #156
Github Notifications (FHIRcast) (Jun 04 2019 at 14:04):
isaacvetter commented on Issue #71:
Closing as resolved in #156
Github Notifications (FHIRcast) (Jun 04 2019 at 14:04):
isaacvetter closed Issue #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.
Last updated: Apr 12 2022 at 19:14 UTC
