FIFO provider splits

[jordansparks]

I just talked on the phone with Dan, a longtime user who has spent the last 8 months branching out on his own code, and is now trying to merge back into the main version without losing all the functionality he built. The main feature he worked on was FIFO patient payments split by provider. (this is not an issue with insurance payments, but only patient payments). This has been on our todo list for a long time as a fairly high priority. He says he's had it working fine for a few months in a production environment. Issues:

1. He created 4 new tables to handle it. He also added one field to the procedurelog table as a flag. This added field will cause his database to fail after he upgrades it to the current version, but he can solve that by repositioning his custom field at the end of the table after the conversion.

2. Moving patients between families makes it hard to tell where the payment should be allocated. We could either lock patients from moving, or, even better, come up with routines to compensate.

My initial reaction was that we already have ProvNum, ProcNum, and PatNum fields in the paysplit table, so all possible splitting should already be accomodated in the database. My opinion was that the allocation was an algorithm problem that could be built on top of the current database schema. When reallocation was necessary, old splits could be altered as needed. But after I thought about it, if he already has it working, then I might rather leave it alone just like he has it. It is already tested. So maybe it would be better to see what his four tables look like and consider adding them to our trunk. Can we see the table schemas?

[dwkrueger]

I am moving forward on this now. I would like to make it it's own dll project to start. The idea being that we make a call for a specfic guarantor number and return a datatable with splits allocated.

datatable will have something like.
Guarantor - Guarantor payment is applied to
OriginalPaymentAmount,
PaymentSource, (there are multiple tables where payments are been put into. So We need to know which table the payment came from.)
PaymentType, (adjustment +ve or -ve, claimpayment, writeoff)
DateofPayment,
ProcNum - The payments or adjustments will be allocated to procedures and will use the procedure's provider for the allocation.
Provider
Ammount - ammount of the split or allocation to the ProcNum specified.

If I put it in it's own dll project then I can keep it's influence on the rest of the development team to a minimum, but when it works move it into the main core (where? I du-know.)

If I do this for one guarantor. Then we can do it dynamically to check it first to see if we like how it is allocated.

I know I commented out 4 tables but I really think I can get it to one table. Say FIFOSplits or FIFOProviderSplits.

I called the project PaymentProcessor_dll. So If I can have the thumbs up all I ask is that you let the project persist in the repository.

Dan

[dwkrueger]

I have finished a major part of the work on the FIFO Split piece of code. I am ready to merge it into the code. But I would like a little guidance. Currently I have it generating the splits as "I" belive the should be calculated then generating a form to review the split data. The form is rough and not really designed for release. I currently have it comming up as a button. I was thinking of just having the button show up if you are using certain flags such as if(DEBUG).

I would like a second set of eyes. On how the splits look. Then we can consider putting the spilt data into the database and figure out the conditions for the splits to be recalculated/adjusted.

Dan

[jordansparks]

You're aware of all the changes in 5.2 related to providers right? You might notice that we NEVER reallocate existing splits. Instead, we simply make adjusting entries after the fact. No new tables were added.
I'm assuming your additions would enhance the existing framework rather than moving in a different direction? We need to talk about it a LOT. If your new code simply calculates splits for the current db frameword, then that's fine. That would be an enhancement. Or are you talking about additional tables in the database? I suppose you could just email me the relevant code for me to look at so we can both be on the same page here.