Enhancements to Aging
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.
Request #1975
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.
Request #712
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.
Request #50
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.
Request #719
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.
|