Multiple Fee Sheet Improvements

(system) #1

sunsetsystems wrote on Thursday, August 04, 2016:

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.


(system) #2

sunsetsystems wrote on Friday, August 05, 2016:

This branch is up to 3 commits. I have created pull request #168 from it.

Testing appreciated!


(system) #3

bradymiller wrote on Saturday, August 06, 2016:


Directed a “up for grabs” demo to Rod’s code here:


(system) #4

bradymiller wrote on Saturday, August 06, 2016:

Hi Rod,
Demo install is showing a install error because of the new column in facilty table:

(system) #5

sunsetsystems wrote on Saturday, August 06, 2016:

Oops, should be fixed now. Thanks for the demo setup!


(system) #6

bradymiller wrote on Saturday, August 06, 2016:

Just refreshed the demo, which is working.

(system) #7

sunsetsystems wrote on Saturday, August 06, 2016:

Zapped a couple more bugs with yet another commit.


(system) #8

sunsetsystems wrote on Monday, August 08, 2016:

Many thanks to Brady for extensive code review and testing. This is now in the SF master.


(system) #9

juggernautsei wrote on Monday, August 08, 2016:

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?


(system) #10

sunsetsystems wrote on Monday, August 08, 2016:

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?


(system) #11

juggernautsei wrote on Tuesday, August 09, 2016:

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.

(system) #12

sunsetsystems wrote on Tuesday, August 09, 2016:

Is there an opportunity to leverage your external process work to improve OpenEMR?


(system) #13

juggernautsei wrote on Friday, August 12, 2016:

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.

(system) #14

sunsetsystems wrote on Friday, August 12, 2016:

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.


(system) #15

mdsupport wrote on Friday, August 12, 2016:

Although we do not use standard Fee Sheet, we use Select2 to avoid these type of display issues. Try playing with this Fiddle.

(system) #16

medfetch wrote on Monday, August 15, 2016:

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.

(system) #17

juggernautsei wrote on Monday, August 15, 2016:

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.

(system) #18

sunsetsystems wrote on Monday, August 15, 2016:

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.


(system) #19

mdsupport wrote on Monday, August 15, 2016:

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.


(system) #20

juggernautsei wrote on Monday, August 15, 2016:

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.