sunsetsystems wrote on Monday, December 05, 2011:
Thanks Tony!
yehster wrote on Monday, December 05, 2011:
https://github.com/yehster/openemr/commits/MultiModSpaceColon
I suggest using preg_split instead of split and handling both colon and space as the delimiter.
My comments on the current commit:
https://github.com/openemr/openemr/commit/5b3648a189a9e2338d6620b2e6d75351d5e5737e
From additional discussion posted in this link:
split is deprecated
http://php.net/manual/en/function.split.php
Should use either explode or preg_split instead.
I believe that
$mods = preg_split("//",trim($this->procs));
will actually make it so that both “:” or space will work. That way we also don’t break this for yourika who provided guidance on this.
Even though “:” was documented as the delimiter to use for multiple modifiers, it really wasn’t correct since doing so would have resulted in incorrect CMS1500 claims. This should handle both scenarios, where if a practice was primarily using CMS1500 and using space, their X12 claims would now work, and if they were using colon for X12 claims, their CMS1500 would now be valid.
jenjhall wrote on Monday, December 05, 2011:
Yes. The colon does not print out correctly on the superbill (at least with ICD9 codes) whereas the space does. - jen
bradymiller wrote on Tuesday, December 06, 2011:
Hi,
Sounds reasonable to have them work for both. Tony, you agree with this?
-brady
tmccormi wrote on Tuesday, December 06, 2011:
Sounds like a ok solution. I’ll see if I can get to it in the next day or two
-Tony
tmccormi wrote on Wednesday, December 07, 2011:
Done and delivered to SF master ….
85f7d13 support spaces and colons as modifier separators, as suggest by yehster
M interface/forms/fee_sheet/new.php
M library/Claim.class.php
bradymiller wrote on Wednesday, December 07, 2011:
Hi,
Rec yanking the error_log() statement. Plan to port this to the next routine 4.1 patch.
thanks,
-brady
tmccormi wrote on Wednesday, December 07, 2011:
Oops, sorry about that. Meant to pull that out before I pushed it… will do.
-Tony w
tmccormi wrote on Wednesday, December 07, 2011:
Done.
fe91893 Remove leftover debugging from multi-modifiers
M library/Claim.class.php
-Tony
yehster wrote on Wednesday, December 07, 2011:
Tony,
Are we storing modifier options/descriptions anywhere in the database at present? or do your customers just tend to use external references to figure out appropriate codes? Should we come up with strategy?
I’m also thinking about what it would take to implement modifiers as 4 separate text boxes. My approach would be to hide the “bill” input field, then keep it in sync with the separate text boxes with javascript onBlur events on the new text boxes.
Would having separate inputs for multiple modifiers be something people would want/use?
-Kevin Yeh
kevin.y@integralemr.com
sunsetsystems wrote on Wednesday, December 07, 2011:
Kevin, the method used for putting entries in the Justify column might be a useful model for that. I.e. a single drop-list would take up less space, and the Fee Sheet is getting cluttered enough as it is.
Just a thought.
yehster wrote on Wednesday, December 07, 2011:
Rod,
We just expanded the width of the Modifiers column to accommodate multiple modifiers. I wouldn’t use any more space than the new fee sheet with my separate text boxes.
In order to implement a drop down list, we’d need to be able to determine the possible options, which would require a lot more “back end work”, plus the current Justify drop down model has some issues of it’s own. For example, you can’t just remove one code at a time if you make a mistake, you have to clear them all and re-add.
sunsetsystems wrote on Wednesday, December 07, 2011:
Hi Kevin, you asked two questions and I was mainly addressing the first. My points are: (1) the modifiers problem is very similar to the justify problem, and consistency within the UI is always desirable, and (2) It’s better to have one selection list than four.
Yes I’m aware that Justify causes some extra work for a user who makes a mistake. But if you’re gonna implement a better selection list method for modifiers, then go for consistency and do it with justify also. I’m not married to the current method, just want the users to have a good experience.
Thanks!
tmccormi wrote on Wednesday, December 07, 2011:
The is no list table for modifiers at this time. There is another complication. A user can enter a code that already has modifiers attached to it using Admin->Services. I have never seen anyone do that, but it’s possible and I’m not sure how that works now … hmm.
The current Fee Sheet may be the worst interface in the system right now, (customer feedback based). I would consider dumping it and designing a good one with more modern style interface (ajax code search for instance). We actually started that a while back there are code shots of it on the wiki and lots of the code is written, just did have time to finish it. I think I’ll start a new thread on that topic.
-Tony
yehster wrote on Wednesday, December 07, 2011:
Rod,
I think the ideal interface for justify, (at least with the current data sources) is different from modifiers, since justification codes come from other entries in the billing table, where as the potential modifiers are from “external sources.”
For justify, I think a better interface would be individual checkboxes corresponding to each of the justify codes, I do worry about clutter with this approach, but I think it would be a more intuitive interface for the user than the current drop down method.
Basically, what I am proposing is having 4 text fields (like on a CMS 1500 form) for each of the modifiers. That way the user doesn’t have to know he needs to use space or colon to delimit. He can directly click on each field, or use tab to switch between them. We could even make hitting the space bar advance to the next field. Having 4 text fields would make it so that the user can easily see the individual modifiers.
sunsetsystems wrote on Wednesday, December 07, 2011:
The Fee Sheet is getting pretty ugly/cluttered because it does so much and recently more has been added. I think this problem is roughly proportional to the number of fields in the form. It’s just getting too much. And even if four fields take up the same space as one, it just looks more cluttered.
By the way, even with the current Fee Sheet I’m not seeing the negative user feedback from users that Tony reports. Indeed, the thing is pretty much a product of what they’ve asked for and were willing to pay to have done.
I have a couple of other thoughts related to that.
1. A tabbed structure for it would surely work better.
2. If you’re not going to do tabs or otherwise break things up, then I vote for not adding any more fields than are necessary. You could still use a single field for 4 modifiers and use JavaScript to force the desired layout within the field.
This discussion, like so many here, is going way beyond the initial scope of this thread. If someone really intends to revamp the UI design soon, then sure let’s talk about it, but otherwise let’s table that discussion until there are resources to do the work. So does anyone want to start on that now, or not?
I’ll attempt to back off now and encourage others to comment.
ajperezcrespo wrote on Wednesday, December 07, 2011:
Feedback that I have received.
Doctors don’t like the feesheet location but do like the pulldowns for coding.
Location because they have to move away from the encounter to code it.
Pulldowns seem to work for them or change it to how the prescription module looks up meds (while typing)
Billers hate the interface and feel it falls short of their needs.
I have seen worse and even more cluttered billing interfaces. I can get screen shots if anyone is interested.
Maybe spliting it might work.
A simple coding interface for the providers. Pulldowns or Lookups.
And a more complex UI for the billers.
The billers interface could have everything needed in one place.
Speaking with billers should give us a better Idea.
And the Tabbing rod mentions also sounds good.
First Tab simple coding
Second Tab more complex stuff
Third tab HCFA Misc Options.
Forth tab X12/1500 billing stuff
Thanks