Does anyone else have issues with frequency limits. When we add the frequency limit in the code specific estimating, it limits the code to once instance per patient instead of to the specific tooth. Ex: If we indicate a 60 month time frequency on a crown and the patient has multiple crowns completed during the year, PW only estimates the first crown as being covered.
Please let me know if there is a solution.
The frequency limit in the estimating doesn't work well for codes that are tooth specific. It can not see that it was used on a specific tooth, it only sees that the code itself was used. This makes it so that if you were to do a crown on #25 and then next month do a crown on #30 it would see that you already performed that crown on #25 and then not estimate it for #30 because it has already been performed within the limit.
On codes that are tooth specific we suggest that you do not fill in the option for the frequency limit.
We found that out as well, so we stopped using that box. In fact, we never use that box for any codes, because if a plan's benefits change, you have to go in and undo/redo everything.
On a related note, it would be really nice if there was an age limit box to check in specific codes.....
We are preparing for the next release. It just so happens I already had this in my proposal (along with three other insurance estimating fixes) which I'm presenting tomorrow. I'll keep you posted.
This is a very aggravating issue. We don't use the box. What we have elected to do to get around this is add yellow sticky notes to that insurance that list the frequency limitations on procedures and it has helped a ton.
We also use sticky notes for benefit info (frequency limits, as well as anything else we can get our hands on). The downside to this is that we have to wipe them out every January, in case anything changed.
Our current proposal to solve this issue involves tying estimating to the tooth number requirement on the ADA code.
Assuming codes are setup correctly, crowns, implants, and other codes are set to require a tooth number in the Transaction Code pick list. We can tell the software that when such a code is performed, check the frequency limit (X number of months) and whether the code requires a tooth number. If a tooth number is required, check to see if the code has been performed on that tooth within the last X months. If not, estimate.
This solution has the added benefit of not requiring additional work on your part (unless the codes in question are not setup to require a tooth number).
If there are any holes in the proposed solution please let me know.