search

masslight / ottehr

Modular, Production-Ready, Open-Source EHR
https://ottehr.com
Other
114 stars 118 forks source link

When all participants leave the call, the patient isn't removed from the waiting queue #98

Closed OmarZubaidi closed 2 months ago

OmarZubaidi commented 7 months ago

See #95 AR point 3

SamirOmarov commented 7 months ago

yeah we discussed this but not sure for full implementation, notes from slack:

We could try to detect when the user leaves the page / closes the tab, but that could have some drawbacks: https://stackoverflow.com/questions/3888902/detect-browser-or-tab-closing Show them an alert telling them if they continue they will leave the call/waiting room?

the solution probably will be browser specific as well.

ncgreene commented 7 months ago

I'll attempt to summarize the problem: We have trouble detecting participants leaving the waiting room because there are a variety of ways they could depart (clicking end call button, closing the tab, turning computer off, etc).

Something that might be worth looking into is server side notifications from twilio: https://www.twilio.com/docs/video/api/status-callbacks

They allow HTTP callbacks to our API to notify us of actions happening in the application. It seems possible that we could update the encounter based on this information.

@SamirOmarov @OmarZubaidi what do you think of this? Any alternative solutions / feedback for this before we bring it to the ZapEHR team?

alexwillingham commented 7 months ago

FWIW it is definitely a long term goal of this service to have Zap listen to status callbacks and other webhooks and automatically document details in the Encounter. Your frontend would probably have to poll the state of the Encounter to glean details from that I guess. Not really ideal?

ncgreene commented 7 months ago

Our FE already polls for the state of the Encounter

ncgreene commented 7 months ago

Moving out of MVP due to high LOE