If you try to make an appointment for a new patient and enter this patient data at the same time then the New Patient Form will occupy the Calendar tab. As a result after you refresh or reload this Calendar tab to get it back the appointment for that new patient will be lost.
I could replicate this behavior using the current demo. Screen shots attached.
This is not a bug in the software. It is the design.
When you go to the calendar, the calendar is expecting the patient to already be in the system to schedule an appointment. If the patient is not there, the system takes on a new path to add the patient to the system. Once the patient add path is completed. The adding of that patient to the calendar must begin a new.
There is not a current method to track all the way through and bring you back to the calendar and assume the patient that was just added is the one that is going to be the calendar appointment.
Hope this helps your understanding of the design of the system verses a bug.
Thank you, @juggernautsei for your comment. I assure you that with my more than 30 years of experience in the IT industry I can see the difference between a bug and a design weakness. But in this case we have both.
First, if by design something doesn’t work as expected it must be accompanied with an error message or a warning and should NOT go through. Second, in no situation a working screen should appear under the wrong tab name. And this is definitely a bug.
I completely understand what you explained about the design. Due to the lack of developer’s resources in such a big and complicated project as the OpenEMR it would take more time to code that function properly. It needs saving the context and the caller reference before the call to be able to return to the Calendar with a proper new PID and make an appointment for the newly created patient. But the system architect has to foresee a user’s natural actions and have some fail-safe mechanism in place especially lacking the detailed manuals and helps.
When I was a developer, then a system architect and then a project leader I found out for myself some universal truth: ‘The Users Are Always Right’. They cannot see inside of our heads and understand whether the system is not behaving as expected by design or by the programmer’s mistake. It does not really matter for them. And btw, Q&A people would also never allow keeping such architectural flaw in the production version.
Please, forgive me for my harsh language but I learnt about this bug in a hard way – doing a presentation of the OpenEMR to my new partner. And after that I also received the same bad news from my other current users. I think something must be done about it anyway.
The words are well received by me. I have only been a developer for the past 5 years and still have a lot to learn. I do agree that the design is incomplete. I remember when one would have to manually go out of the calendar appointment and enter the patient then come back to the calendar and enter the appointment. I don’t know who built the incomplete process but it is better than it was but still not complete as you so pointed out.
Not being funny. It is people like you who come into the project and lend a helping hand which keeps the project moving forward. If you could implement the design and architectural changes. It would benefit everyone in the community and beyond.
I do wish to be a better developer but that, I have learned, takes time for some of use that are not gifted. I have seen some gifted people come into the project and then leave. I hope you stay around for a while. I could learn some good things from conversations like this.
When I am developing a process, I try to think of how an end user would use the program after I am done no matter my intent or thoughts. Some times I can and most time people end up doing things I could not imagine them doing.
The Weno module is one of those things that needs more safeguards in place. I see how people are using it and there are simple little things that are keeping user from having a great first experience but time and resources keep me from getting around to fixing the code. Most of the developers that contribute to the project are part timers. There are some that are full time but won’t commit work because we are all trying to have unique feature sets to attract customers. So, a lot of the good stuff gets held back because there is no money in giving everything away.
So, that is how we end up with the calendar like it is.
Thanks for writing back and hope to see you around.
