Modifier handling in Fee Sheet List

Our providers do their own coding and really appreciate the presets facilitated by the Fee Sheet List (Admin->Forms->Lists->Fee Sheet).

However, their presets often contain codes that need to be billed with a modifier, and the Fee Sheet List doesn’t handle that correctly. When selecting codes to be included in a preset, the dynamic code picker does not display code modifiers. Also, if the code exists in Admin->Coding->Codes both with and without a modifier, even if you can discern which code to pick (perhaps by description) from the picker, you won’t be able to save the code with a modifier in the Fee Sheet List because it will get replaced by the code without a modifier due to this query.

@sunsetsystems suggested some time ago that a code with a modifier should be created in a particular way in order to be handled correctly. However, that fails as well, albeit in a different fashion.

I performed the following testing procedures on https://demo.openemr.io/a/openemr:

  1. Created three CPT codes via Admin->Coding->Codes:
    a. 44444, with Modifier: 25
    b. 55555:25, with nothing in the Modifier field
    c. 66666:25, with Modifier: 25

  1. Added the created codes to a preset Option in the Fee Sheet List

  1. Created an encounter for a patient and selected the preset code containing the three added CPT codes, which resulted in the creation of line items for each. For code 44444, the description was included but not the modifier or price. For codes 55555:25 and 66666:25, the modifier was included (created?), but not the description or price.

  1. Created a different encounter for the patient and added the codes individually from the “Search for Additional Codes” section on the Fee Sheet itself. This resulted in the code 66666:25 and 55555:25 line items having a modifier but no description or price, and code 44444 added correctly with description, modifier, and price included.

Is there a workaround for proper modifier handling via the Fee Sheet List?

1 Like

@snailwell this has been a sticky wicket for a long time. There are no better workarounds that I know about. I did go through the same process you did on the demo. The same results occurred to me also. There is a bug in the code where adding the “:” modifier breaks the adding of the description and price.

I looked at the dropdown and the options are the same whether there is a modifier added with the colon or not. The issue is in the fetch when the item is selected. Adding the colon the system does not fetch the price. Without the colon attached to the code, the price is returned. This is where the bug lies.

There is an observable that is not working correctly. Maybe @sjpadgett can jump in here and do a quick fix of this bug

I’ll take a look though after my last foray into batch payments, I swore off billing!:slight_smile:

1 Like

Man! The fee sheet has become very convoluted(not necessarily in too bad of a way).
This will take me a little longer to tackle. Perhaps tomorrow.
We also need to visit our code selectors and get some sense of single purpose and develop a set of classes.
Perhaps a milestone for our next release along with a valueset.

1 Like

Has anyone seen this new issue where search resuts dropdown only one item. The sqlFetchArray() only gets one value then fall out of while loop.
This is windows…

Anyone hate the yellow search results as much as I do?

I certainly hate that there is a extra click involved with seeing the results.

agreed. will see if I can auto expand.

1 Like

Just so you guys know, it’s not possible to open a select dropdown from javascript. We’d need to convert to a select2 which is one of the big reason we have select2. Sorry @snailwell

2 Likes

Info on what was fix is here: Fix feesheet option list to include modifier if available. by sjpadgett · Pull Request #6382 · openemr/openemr · GitHub

2 Likes

Good to know.

Given the choice, a drop-down there wouldn’t be what I’d use for the design of that . At the point you click the “search” button, you expect to see the results displayed, not hidden in a drop-down that requires a click to expand. A table with “plus” or “ADD” buttons next to the codes found via the search would seem to make the most sense. Oh well.

I imagine the pushback to that would be what would happen if the search returned too many results, but I would argue that most code searches wouldn’t return too many results, and perhaps pagination could be implemented if that was an issue.

I don’t disagree but I don’t have time to rewrite. Really should be a collapsible panel with scroll.

1 Like

Thanks @sjpadgett for taking time to fix this bug/contribute feature!

optimized

1 Like

Just repayment for the great portal validation fix!

1 Like