1)Changed Calendar Look. Categories in calendar are split in to Patient and Provider.
2)Added a new feature to duplicate an appointment.
3)Added new field for facility for the different color code for each facility.
4)Changed onset date to default `blank`.
5)Minor Correction in claim.class.php for conforming to the nucc data set standards.
6)Provider can select the facility under which the encounter has to be billed(Both calendar and encounter creation).
I was testing your billing and calendar modification right now…i have a few query and questions regarding the new calendar look and its utilities, which i cant understand…
1. Whenever i login into openemr, the calendar is shown. in the new model, its working fine and there it shows the name of the facilities below the facility /providerselection box. Now when i select a particular facility from the box, the name of that facility is no longer shown in the space below the facility/provider selection box. why is it so? whats the idea behind it?
2. Suppose i have one facility only. in that case, do i need to select a colour in the add facility box in administration->facility? if i do that, then the whole calendar gets coloured with the same color i select and there is no demarcation between the lunch and the other time slots (Previously lunch was shown distinctly as yellow colour)
4. Suppose i have two facility, FAcility A and B. I share a common database. Does the patients for facility B visible to Facility A and vice versa? if that is so, how to fix that. i want to restrict each facility to see their own patient. please help on that!
For (4): Yes, patient visibility is not restricted based on facility. There is an incomplete implementation in the current tip, but I don’t recommend using it without improving it. Ytiddo has a (set of) patch(es) that accomplishes that, but I’m not sure if they are completely ready to be committed. Ytiddo’s patches also introduce a new ACL so that some users can see all facilities.
Finally, while there have been multiple requests for this “feature”, I’m not sure it’s really what you want. If a user accidentally changes a patients facility, they stop being able to even find that the patient exists, which means they can’t get it back. Also, when entering a new patient the search for duplicates might miss the same patient that had simply moved to a different facility. Duplicate patients like that is usually quite bad, since we have no process for identifying them or merging them, you basically just have to let an SQL guru crawl through the database and do the merge manually.
Ytiddo,
Could you publish that patch/those patches somewhere so they can get reviewed and possibly committed? I’d hate to see more work duplicated in that area. If you need help isolating you patch(es) from the rest of that work, let me know.
1. Consider adding a field that separates physician/patient appointment categories that can be set in the Adminsitration->Calendar gui. Could even base this on a list in list_options, so users could add additional categories that are given their own tabs in the scheduling pop-up.
2. As Arnabnaha discussed above, the code is a bit intrusive since it now color codes everything by the facility (and doesn’t follow the settings that are stored in the categories via Adminsitration->calendar gui). Several possibilties include going to old behavior when only one scheduling facility is set, placing a flag in events that are facility dependent (such as patient appt, in, out, but not things like lunch), control it with a global, a combination of these possibilities, or I’m sure other testers/developers may have some other ideas.
We have removed redundant lines of code from 3 view files(day,week,month).
Further more unification of the code seem to be practically not feasible.
Functions are added in add_edit_event.php to reuse the code.
The update query filling the billing facility is coded in the update sql.
The code level comments in the previous commit are also addressed.
I posted my review on github. This is looking really nice, although still a couple of moderate issues (which I posted on github). It will be very helpful for Tony and Rod to review this also, especially at the billing specific code.
I reviewed this billing code in the earlier post and tested it as well. It seemed to be good and to correct some issues. I’ll look it thru again to be sure.
-Tony
bradymiller’s git hub comments for the branch calendar_and_billing_location_modifications_v4 is corrected.
Also comments are added in the above commit against the review.
Paul,
Your group rocks. All looks good to me. As long as I get an ok form Tony or Rod on the billing portion, then I’ll gladly commit it. (for your group’s scanned documents code review, gonna try to get to it in the next couple days).
thanks,
-brady
I have added a few comments to the commit f972d…. Please search for “sunsetsystems” to find them. I’m especially concerned about a possible misunderstanding re the use of facility.billing_location.
Rod Roark’s git hub comments for the branch
calendar_and_billing_location_modifications_v4 is corrected.
facility.billing_location is now the old boolean type.
Also comments are added in the above commit against his review.
I saw one possible error that I added a commit comment for. So let Paul check that first. Otherwise I only skimmed the code and have not tested… if it tests OK then I’d say go ahead. Thanks Paul and Brady!
Minor bugs that I noticed on testing recommend fixing:
1) The Refresh button on the calendar shows the browser warning ‘To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier.’ if click Calendar-> Week->Refresh.
2) The encounter add screen shows a blank for Onset/hosp. date:, however when editing an encounter it shows 0000-00-00 (probably best to make it blank again if it equals 0000-00-00).