Problems on EHR Demo Sites

I am investigating, but there are a lot of odd happenings with the EHR Demo as deployed right now.

The Log Viewer (Administration>Others>Logs) does not currently work. I checked on multiple sites.

Also, I see an ajax call to “https://nhanes.librehealth.io/modules/calendar/includes/get_provider_events.php” in my network log happening continuously. (About every second…)

As I learn more details, I will share figure out here and as issues on github.

Not sure what changes have been made recently that might be contributory factors, so if other have insight that would be appreciated.

The calendar was replaced and made a module. The link we use for the nhanes date is this one https://ehr.librehealth.io/interface/login/login.php?site=nhanes . Is the error happening there? Thanks for looking at this.

Yes. That is the link I used to generate this screenshot. The requests to get provider events at the bottom are never ending.

1 Like

Ok… It looks like this is intentional, but it is not an acceptable design decision.

Continuous polling every 3 seconds? That is absurd.

there a global option for it you can set it to 10 seconds. Does it need to be longer?

Even at ten seconds it’s a terrible design. The calendar data doesn’t change that rapidly. Was there any thought to the performance implications of all those extra requests? I also worry about potential blocking issues with the session object if multiple ajax requests are being fired concurrently.

Also, does this continuous polling break the automatic timeout/log out process which is a major security requirement?

The intent was to allow an auto refresh of the calendar screen. If you can supply a better design that would be greatly appreciated. I guess we should provide a way of turning it off (sorry for the issues) I will add a global to turn it off and change the timing to be 1, 5, or 10 min’s .

@yehster I am testing the changes that I mentioned above. I need to add a refresh button when the auto refresh is disabled. Should have them shortly.

Do you think 10 minutes is long enough as a maximum choice?

I think 10 mins should be maximum time to refresh. The default should be 5 mins.

The “refresh” icon on each tab will refresh the window. Maybe we should just make that larger and add a tool tip?

Instead of an explicit refresh button, having the calendar autorefresh on an event like “focus or mouseover” of the calendar window would save the user a click. This way if the auto refresh rate is turned down to a few minutes, the user will still see changes by others if they are idle in a reasonable time frame, and when the are actively reengage with the window it will reflect the immediate state.

As an aside, the new “week view” doesn’t serve the same purpose as the old version did. The user should be able to at a glance see all the appointments for the week so they can easily pick an open slot during the week.

If you could do this it would be great!

Not sure how to go about doing this but I will look in to it.

Some slightly larger icons, tooltips (for a lot of things) and some massive reduction in whitespace (in a lot of places) would really be useful.

The refresh icon isn’t easy to notice. I just realised it exists. We need larger icons + tooltips here.

Is it too late to make “improvements to the tab icon sizes” a Google Code In task?

Do you think the 13 to 17 year old’s can do it?

This will be a good GCI task. If the task has a good description, then they’ll be able to do it.

@Trodrige you want to set up the task?