On current OpenMRS version 2.x is not possible to update the time of the visit.
This is a problem if we try to fill an encounter in the same day of the visit but a few hours before the visit start time.
Use case:
A possible scenario is that often the patient comes in, but they don’t have time to start the visit. An hour later they come, start a visit and create an encounter and change the hour to reflect the reality. The problem is the hour of the form is an hour earlier then the start of the visit and we can not modify the visit hour but only the date.
A couple of possible solutions:
Allow the user to edit visit time (not only the date)
Threat the visit as date, saving the start time at midnight (same behaviour as when we edit the current visit date) and the end date at 23:59h
Please, let us know what is the best approach to follow.
@mseaton@mogoodrich Your input here would be valuable. Initially, we had tried to enable the user to edit the time of the visit, but it didn’t work because the controller for that does not allow changing the time if the date is on the same day. It looks like the intention here was that a visit have a date only, but visits are being created with a date and time (which probably isn’t a bad thing), we just have no way to edit that time.
This all makes sense, not sure exactly what the answer is.
The widget that you reference doesn’t allow selecting a time at all, correct?
I’d be fine with changing the widget via a configuration (that defaults off) to allow changing the time, or to provide the user with the ability to set the time of the visit to 00:00 (which is all that is needed to do in this case). The challenge for the latter is that it would be hard to create a UI that is clear to the user?
To explain the rationale between for the current behavior (for better or worse):
When starting a new visit, if the start date is today, assume this is a real-time/POC visit and timestamp with the current time
But if the start date is in the past, assume this is not real-time/POC and time is unknown, so timestamp to midnight
The clause you are highlighting is just there (I believe) so that if the user opens the visit edit dialog and saves it without changing anything, it doesn’t inadvertently blow away the time component.
Of course, now when I test on one of our demo environs, I think it is zeroing the date on save… I’ll fire up a local dev environ to see if I can clarify what is happening.
Okay, so I realized in my testing above, in the PIH EMR we have a custom visit page, which was displaying the behavior I was seeing… I reproduced the issue you are seeing on the Ref App demo server.
My thoughts above still stand about particular workarounds above.
Also, the super-annoying workaround until a fix is in, would be to change the visit date to something other than today, and then change it back to today.