This page is intended to act as a roadmap for where our patient accounting system is headed and how it should be organized. There have been extensive discussions over the years on how we should handle it, and this page attempts to incorporate all of those discussions. This page is only for very advanced users who are very familiar with our accounting method and are interested in improving it.
The Main Goals
FIFO so that provider income may be tracked.
Some of these goals seem to conflict slightly with other goals. But we can all agree that FIFO is by far the most important.
2. Force users to split insurance payments.
1. Insurance payments are currently split by patient/provider/procedure as they come in. This automatically and very cleanly allocates the income to specific providers who actually did the work. We think this is a very accurate and elegant solution which does not need to be changed. But there is a request for the incoming payments not to be applied as indicated by the splits, but instead to be applied to the "bucket" and split on a FIFO basis according to all the other patient and insurance payments that have been made. The reasoning is that the provider should not be rewarded for doing treatment when the patient has not paid for previous treatment. The insurance payment should go to the provider who did the previous unrelated treatment. We could handle this by an automated income adjustment that is made at the time of entry of the insurance payment.
2. Delayed payments. We have had a request for payments that are made ahead of time to not show up in the income report until the treatment is completed. The reasoning here is that the provider shouldn't be paid for their work if they haven't yet done it. Our counter argument is that if the patient doesn''t do the work and gets a refund, then the resulting negative income entry would reduce the provider's income by the appropriate amount, and no harm would have been done. But this does not seem to satisfy the user, since they don't want the provider to have been paid in the first place.
3. Unallocated payments. One request is for some income to be applied to no provider at all. The reasoning seems to be that sometimes, you simply won't know whom to apply the payment to, so the system shouldn't force you to pick a provider. This does not seem like too difficult of a request, although it would very likely mess up most of the current income reports that we have. We don't see a clear enough reason for this request yet.
4. True line item accounting. This has been the most difficult request. One potential user in particular has been very persistent about this one feature for a number of years. DenTech, an older Unix dental software, is acting as the model for this request. Apparently, DenTech has a very good and accurate way of applying income to individual procedures as it comes in. Once a procedure is paid off, it is "closed". So the next payment gets applied to the next open procedure. When I asked how incorrect allocations were handled, the response was that they "simply make an adjustment". That seems like it might be messy, but in the end it is also the most accurate. This is what patients seem to always want to know, "what is this payment being applied towards?" This has been our model for the last few years.
Open Dental Software 1-503-363-5432