Enhancements to Aging
Aging of A/R Report
As with all Feature Requests, the ones listed below are not set in stone and there is no possible way to estimate if or when
they might be added. The intent is for this to stimulate discussion to help guide future programming.
2692: Interactive Aging Report
The Aging and A/R reports need to be merged into one interactive window. The columns should be selectable. The data should be exportable. The table would be generated on screen first and then printed if needed. Should be able to jump to patient accounts. The following additional changes have been requested for the aging report:
72: A/R Report.
396: PPO writeoffs by procedure date
27: PatNum, BillingType
331: Sort by amount owed
474: Exclude small amounts
720: Payment plans show
937: One page summary of totals
938: Show percentages of totals
1180: Back dated reports.
-Column for last statement date.
-Show only patient portions so that list can be much shorter.
-The current Aging report uses ProcDate, and the ProdInc report uses DatePay. If a user wants to correlate the two, it would be nice if the Aging report gave the user a choice between which of the two date fields to use. The workaround is to ensure that both dates are always the same for all procedures and to use a report to catch those that are not.
Many of the above requests do not have any votes yet. But making the A/R report interactive would provide a good foundation for implementing these requests.
Aging calculated by patient and provider rather than by family guarantor. The user would then have the option of grouping by family, by patient, by patient/prov, etc.
Locking history. In other words, historical entries would have the appearance of being editable, but what would really be happening in the database would be the addition of
more rows. No row would ever be changed or deleted, no matter what permissions the user had. This is the same technique currently used to allow editing of procedure notes, while still keeping a perfect historical record.
More automation of patient payment splits by provider or procedure.
This would allow allocation of every payment split to a specific procedure. Aka open item accounting. The trick is that when insurance comes back, the original patient payment splits might need to be reallocated. And of course, that wouldn't be good for Accrual Accounting unless absolute history locking were in place as described above.
Change aging behavior. Would follow request #50 above. Because payments would be tied to specific procedures, aging calculations could take advantage of this rather than using FIFO as we do now.