I am beginning work to synchronize the project with improvements done for IPPF. The first commit for this mostly concerns the Fee Sheet and has several new features. They are described in the comments for the commit which may be found here:
Note especially the "modularization" of the Fee Sheet that moves much of the "business logic" into a new class. This will come into play further with an upcoming feature that adds fee sheet features to layout-based encounter forms.
It looks good so far on basic testing here. More testing and comments appreciated. Send me a note if you want access to my test site.
Rod
rod@sunsetsystems.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I seem to be always running right behind you guys in the same areas of the program with that said. I have working around the fee sheet and found an issue that we are having with the units and price.
If the unit is one there is not problem. But if the unit is anything other than one, every time the fee sheet is opened and saved. The calculations are repeated.
Say the first time the fee sheet is opened and filled with 8 units at $15. Save the sheet and the math is correct at $120. Open the fee sheet and close it again doing nothing but just opening and clicking save. The price becomes $960.
Are the changes to the fee sheet going to address the math issue?
Sherwin, the Price column in the Fee Sheet is per-unit price. For existing database line items it should calculate that as fee / units. This appears to be working in current code. Not sure where you are seeing this math issue?
We had setup another process to fill the billing table and when the biller would have to use the fee sheet to make corrections this issue was arrising. So, the fix was to do the correct math in the other process and store the (unitsxprice). Problem solved. Now when she opens the fee sheet and it divids the total by the units, they see the units and the base fee $15.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As you can see in the video the other process the fills out the fee sheet has it's user interface in the eSign UI and the background work is done in the /interface/forms/custom_odt folder where the update_fs.php and the popup.php are located.
This works because we made the calendar categories CPT codes like Assessment: H0031. This make the rest of the system able to fill out the fee sheet by marking an appointment closed in the workflow.
Looks like the picker widget does wrap the description but does not show the code, in the case of using Service Categories. Try it out when you get a chance.
I tried to configure the code suggestion. It was about two hours in that I gave up. The drop downs are styled by user agent stylesheet and there is an adverse effect when overridden by !important. So I had to back out of that and looking for another way to wrap the text or use shorter discriptions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is very odd. If select2.css and other css overrides are included at the end, the rendering engine cannot act retroactively. In our case it has not affected other tags in 10s of pages.
You always have option of using short text when building the list but with ICD10s short texts still can be long.
Best.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you answered my delima in that I had above the end of the css rendering engine.
Well that did solve the issue of overwriting the user agent stylesheet. I placed the code at the bottom of the style_metal.css and it did not overwrite the user agent.
There is some nice functionality included here.
I noticed two things, one old, one new.
When the user checks the delete box for a CPT4 code (but not ICD), and then "refreshes" the page, the strikethrough occurs but the line is prepended with "ike>". This has been around for a while.
The other very minor suggestion might improve usability by reducing end-user hand movements: when a user enters text into the search box, the focus is shifted from New patient to Search button, allowing the user to hit enter/return rather than mousing over to press Search, then move to the Search Results so the arrow keys work here. The flow would be:
Type searchterm, hit enter, scroll list with arrows, enter to select.
Predictable and fast and does not interfere with the users ability the lumber around with the mouse/trackpad if they want.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Ray, I noticed the "ike>" thing also and as you say it was there before. Seems to be a byproduct of the Justify widget that KY created, and the cause was not immediately obvious (lots of client-side stuff going on) so I didn't fix it.
I am beginning work to synchronize the project with improvements done for IPPF. The first commit for this mostly concerns the Fee Sheet and has several new features. They are described in the comments for the commit which may be found here:
https://github.com/sunsetsystems/openemr/commit/d6cdc54da57bd208adc5fc7c5a745853834dbc81
Note especially the "modularization" of the Fee Sheet that moves much of the "business logic" into a new class. This will come into play further with an upcoming feature that adds fee sheet features to layout-based encounter forms.
It looks good so far on basic testing here. More testing and comments appreciated. Send me a note if you want access to my test site.
Rod
rod@sunsetsystems.com
This branch is up to 3 commits. I have created pull request #168 from it.
https://github.com/openemr/openemr/pull/168
Testing appreciated!
Rod
http://www.sunsetsystems.com/
Last edit: Rod Roark 2016-08-05
Hi,
Directed a "up for grabs" demo to Rod's code here:
http://www.open-emr.org/wiki/index.php/Development_Demo#192.168.1.132
-brady
OpenEMR
Hi Rod,
Demo install is showing a install error because of the new column in facilty table:
http://demo.open-emr.org:2106/log/logSetup.txt
-brady
Oops, should be fixed now. Thanks for the demo setup!
Rod
http://www.sunsetsystems.com/
Just refreshed the demo, which is working.
thanks,
-brady
Zapped a couple more bugs with yet another commit.
Rod
http://www.sunsetsystems.com/
Many thanks to Brady for extensive code review and testing. This is now in the SF master.
Rod
http://www.sunsetsystems.com/
I seem to be always running right behind you guys in the same areas of the program with that said. I have working around the fee sheet and found an issue that we are having with the units and price.
If the unit is one there is not problem. But if the unit is anything other than one, every time the fee sheet is opened and saved. The calculations are repeated.
Say the first time the fee sheet is opened and filled with 8 units at $15. Save the sheet and the math is correct at $120. Open the fee sheet and close it again doing nothing but just opening and clicking save. The price becomes $960.
Are the changes to the fee sheet going to address the math issue?
Sherwin
http://www.openmedpractice.com
Sherwin, the Price column in the Fee Sheet is per-unit price. For existing database line items it should calculate that as fee / units. This appears to be working in current code. Not sure where you are seeing this math issue?
Rod
http://www.sunsetsystems.com/
We had setup another process to fill the billing table and when the biller would have to use the fee sheet to make corrections this issue was arrising. So, the fix was to do the correct math in the other process and store the (unitsxprice). Problem solved. Now when she opens the fee sheet and it divids the total by the units, they see the units and the base fee $15.
Is there an opportunity to leverage your external process work to improve OpenEMR?
Rod
http://www.sunsetsystems.com/
Yes, but it is specific to the way a behavioral health system runs. They wanted the billing done in the work flow. It is explained here
I can make it available for pick through and see what can be used.
On the fee sheet improvements will the descriptions be fixed so that they wrap and show the code?
I had a request to fix this.
Here is the repository that goes with the video
As you can see in the video the other process the fills out the fee sheet has it's user interface in the eSign UI and the background work is done in the /interface/forms/custom_odt folder where the update_fs.php and the popup.php are located.
This works because we made the calendar categories CPT codes like Assessment: H0031. This make the rest of the system able to fill out the fee sheet by marking an appointment closed in the workflow.
Last edit: Sherwin Gaddis 2016-08-16
Looks like the picker widget does wrap the description but does not show the code, in the case of using Service Categories. Try it out when you get a chance.
Rod
http://www.sunsetsystems.com/
Although we do not use standard Fee Sheet, we use Select2 to avoid these type of display issues. Try playing with this Fiddle.
I tried to configure the code suggestion. It was about two hours in that I gave up. The drop downs are styled by user agent stylesheet and there is an adverse effect when overridden by !important. So I had to back out of that and looking for another way to wrap the text or use shorter discriptions.
That is very odd. If select2.css and other css overrides are included at the end, the rendering engine cannot act retroactively. In our case it has not affected other tags in 10s of pages.
You always have option of using short text when building the list but with ICD10s short texts still can be long.
Best.
you answered my delima in that I had above the end of the css rendering engine.
Well that did solve the issue of overwriting the user agent stylesheet. I placed the code at the bottom of the style_metal.css and it did not overwrite the user agent.
Last edit: Sherwin Gaddis 2016-08-15
There is some nice functionality included here.
I noticed two things, one old, one new.
When the user checks the delete box for a CPT4 code (but not ICD), and then "refreshes" the page, the strikethrough occurs but the line is prepended with "ike>". This has been around for a while.
The other very minor suggestion might improve usability by reducing end-user hand movements: when a user enters text into the search box, the focus is shifted from New patient to Search button, allowing the user to hit enter/return rather than mousing over to press Search, then move to the Search Results so the arrow keys work here. The flow would be:
Type searchterm, hit enter, scroll list with arrows, enter to select.
Predictable and fast and does not interfere with the users ability the lumber around with the mouse/trackpad if they want.
Hi Ray, I noticed the "ike>" thing also and as you say it was there before. Seems to be a byproduct of the Justify widget that KY created, and the cause was not immediately obvious (lots of client-side stuff going on) so I didn't fix it.
I like your suggestions for the search tool.
Rod
http://www.sunsetsystems.com/