teryhill wrote on Wednesday, March 02, 2016:
This commit allows line items to be excluded from insurance submission. Ths was started by MI2. You can specify codes to exclude in the codes table . The commit is here
Thanks
Terry
teryhill wrote on Wednesday, March 02, 2016:
I have users that bill things that the insurance will not pay for and they don’t want it to be filed with the insurance company. Things like a charge for a copy of medical records, procedures that are not covered. They were creating two encounters and seperating them that way.
If that is not what you were asking let me know.
Thanks
Terry
sunsetsystems wrote on Wednesday, March 02, 2016:
Thanks. My thinking is a new code type (other than CPT4) can be created for charges like that. Inappropriate code types should not be submitted to insurance, or if they are then that’s the problem to fix.
Rod
tmccormi wrote on Thursday, March 03, 2016:
My customer uses standard CPT codes but records the normally charged price and excludes it. Then adds it again with the rate the Medicaid payor accepts. This is because they need to report both (to different government entities). It’s the solution they preferred, I had other thoughts I liked better, but they got what they wanted.
sunsetsystems wrote on Thursday, March 03, 2016:
Not sure I followed that. But couldn’t they invent a different code type for charges to be excluded from insurance? Also payers will generate an adjustment for charges in excess of what they cover. But you already know that.
Rod
teryhill wrote on Thursday, March 03, 2016:
I would like to see an example of what you are thinking about Rod. If the code gets filed to the insurance company does alter what they would have paid if it had not been included?
Thanks
Terry
tmccormi wrote on Thursday, March 03, 2016:
This is an FQHC (Federal Qualified Health Clinic) the reporting requirements are strict and vary by the program. Billing anything to some payors that is not exactly what the contract called for will get the claim rejected.
On the other hand the Feds want reports of the CPT codes and services performed based on the standard RVS charges for the geographical area and the clinic… The clinic can claim the difference as contributed labor costs in some wierd way.
The customer want full control by the biller of what was coded, what was billed and to who it was billed and in what order. (remember the drag and drop reording feature?)
I agree in the other case, where there are internal non billiable service codes, that a separate custom code type is more appropriate.
sunsetsystems wrote on Friday, March 04, 2016:
The question is do we want this change in the project. My impression is that it sounds more like a need for a custom report than a need to add another attribute to billing codes.
If I’m understanding correctly, one possible approach would be to use two price levels: one for billing, the other for reporting to the feds. A custom report would be written to look up the second one in the codes and prices tables for each billing item being reported.
Or instead of multiple price levels, you could store the prices for the feds in a custom list, or under a custom code type, and the report could look them up there.
However there may be other use cases, and comments from anyone are welcomed.
Rod
tmccormi wrote on Friday, March 04, 2016:
I think the option/feature is very valid. The multiple price list option is possble for some versions of this but not what the customer(s) wanted, We are all about optioning things like this. (see Athletic teams, NewCrop, Discounts, Referrals in encouters and more…)
Either we are open to these kinds of options or we are not and need to change the policy to use a separate “plugin/Module” method for all options (which would be cool).
I think the description of the option needs to be more related to what it is “Option to Exclude Certain Service Codes from Claims billing”
sunsetsystems wrote on Friday, March 04, 2016:
I think this is a communication problem. Am very much open to options, just looking for a use case that I understand to justify the small amount of extra clutter. “This is what the customer wanted” is not that. Thanks.
By the way I don’t know of anyone using the Athletic Teams stuff any more. That should probably be removed, at least from global settings. Needless clutter is evil.
Rod
teryhill wrote on Friday, March 11, 2016:
If the child is never allowed to come forth from the womb all die.
sunsetsystems wrote on Friday, March 11, 2016:
Can you try again with a use case that my feeble brain can understand? 
Keeping in mind the availabiity of custom code types and price levels.
Rod
teryhill wrote on Friday, March 11, 2016:
RIP
tmccormi wrote on Friday, March 11, 2016:
I vote we accept the code. Rod is not the only deciding factor in what get’s into the source base.
sunsetsystems wrote on Friday, March 11, 2016:
Never said I was. Just asking “Why?”.
For what it’s worth, one of my own recent proposed commits was shot down. What goes into the project is based on logic, nothing else. There’s no room for egos here.
Rod
teryhill wrote on Friday, March 11, 2016:
No EGO here . Commit pulled. To old and too busy for the why torture chamber and don’t like roller coasters.
Will work on some other things for my users.
Thanks
Terry
tmccormi wrote on Saturday, March 12, 2016:
No ego here either, I was and am asking for some other members of the community to comment. Terry and I have explained it’s use and use cases with our users. We think adequately.