270 likes | 455 Views
Tennessee Customization with Overnight Processes. University of Tennessee College of Dentistry Frank Pancratz. Tennessee Customization with Overnight Processes.
E N D
Tennessee Customization with Overnight Processes University of Tennessee College of Dentistry Frank Pancratz
Tennessee Customization with Overnight Processes This presentation will cover 4 areas where overnight processes have helped us: • Managing Payment Allocations • Managing Student Evaluations • Managing Patient Recalls • Managing Record Locks
Tennessee Customization with Overnight Processes Managing Payment Allocations
Managing Payment Allocations • Tennessee Business Rules • ADA procedure codes requiring more than one visit to complete and costing more than $100 require at least half-payment at time code is put “In-Progress”. • ADA procedure codes requiring lab fabrication must receive at least half-payment before fabrication will begin.
Managing Payment Allocations • Situation (aka the Problem) • Patient needs 2 crowns. • The patient pays $365, which is half of the price of both crowns. • Existing FIFO logic applies $365 as payment in full for the 1st crown and leaves the 2nd crown unallocated. • Lab manager refuses to fabricate 2nd crown until system shows at least half-payment has been received.
Managing Payment Allocations • Solution: • TENN_APPLY_ALL_PAYMENTS and TENN_APPLY_ALL_PREPAYMENTS These customized processes apply unallocated patient payments so that half of the total cost is satisfied on ADA procedure codes identified in table PROCEDURE_BILL50 that have a status code of “IN-PROCESS”. • APPLY_ALL_PAYMENTS and APPLY_ALL_PREPAYMENTS These standard processes are run, after the processes in #1 above, to perform FIFO processing of any remaining unallocated payments. NOTE: Our cashiers actually allocate 90% of patient payments, so these processes serve more as a “Safety Net” to catch and process unallocated payments.
Managing Payment Allocations ADA Procedure Codes included in table PROCEDUR_BILL50 for half-price processing
Tennessee Customization with Overnight Processes Managing Student Evaluations
Managing Student Evaluations • Situation (aka the Problem) • Our Axium grade forms are not consistent. • We want to give our department directors the flexibility they need. • We want to account for Grades/Evaluations and Points that students earn in any discipline, for any period (even prior to Axium) on one consolidated report.
Managing Student Evaluations Different data elements are captured from the grade forms depending on the Discipline and Form involved. In the examples shown, the highlighted data is what we want to capture from each of these particular grading forms.
Managing Student Evaluations In FPROS dept, Points and Grades are awarded on ADA procedure codes. Emphasis is on the number of procedures completed.
Managing Student Evaluations In ORAL SURGERY dept, the grades are recorded in the upper section of the grade card. The emphasis is on number of encounters, not number of procedures.
Managing Student Evaluations • Solution: • UT_POINTS_SELF_SERVICE This process collects and merges data from Axium and our prior system and creates a new database table UT_GRADE which is then used for producing grading reports using Crystal Reports. (The disadvantage to this method is that grades and points reflect the prior day’s totals, instead of up to the minute tallies.) • UT_BUILD_POINTS This process collects points awarded from Axium and our prior system in the various disciplines by provider and creates a new database table UT_POINTS which is then used to produce point reports using Crystal Reports.
Managing Student Evaluations Example of Grading Report using new database table UT_GRADE
Managing Student Evaluations Example of Points Report using new database table UT_POINTS. By using Points we could easily compare student-to-student and year-to-prior year benchmarks.
Managing Student Evaluations • FYI The University of Tennessee is currently in the process of transitioning away from a point system in favor of… a hybrid system consisting of multiple clinical requirements. For a copy of the current University of Tennessee Clinical Expectations documents please send me an e-mail at: fpancratz@utmem.edu
Tennessee Customization with Overnight Processes Managing PATIENT REcalls
Managing Patient Recalls • Goals for automated process • Eliminate duplicate recalls • Set recalls that have been satisfied to status ‘COMPL’ • Update recall provider to the student currently assigned as the patient’s primary care provider • Consolidate PERIO, HYG, GHYG, and GPERIO recalls into one recall (the last one entered)
Managing Patient Recalls Our process looks at the TRX.”Procedure” for the ADA Code that satisfies the recall. It then updates the PTRECALL.”Status” to ‘COMPL’ where the PTRECALL.”RecallDate” < TRX.”TreatmentDate”
Tennessee Customization with Overnight Processes Managing RECORD LOCKS
Managing Record Locks • Our overnight processes for managing record locks fall into two categories: • Financial Locks – basically require the patient to stay current with their financial obligations to the College of Dentistry. • Insurance Locks – aid us in verifying patient data so that payment can be received.
Managing Record Locks The PROM – Financial Lock begins by the staff member accepting partial payment from an emergency clinic patient. By entering the keyword “PROM” in the Code section we can then track the presence of this word in our automated process to LOCK the record. When the patient pays the staff member removes the word “PROM” from this note so our automated process will not LOCK the record. (The automated process looks for PTNOTE.”NoteCode”=‘PROM’ and sets PATIENT.”Office1”=‘PROM’)
Managing Record Locks In Axium, Maintance/Chart Tracking Locks/Electronic Chart Lock, we have an Office Code = PROM, which triggers the actual record lock.
Managing Record Locks The BALOD – Financial Lock starts with a patient having a debit balance for 90 days or longer. In our automated process we use the PTBAL database table. As part of our overnight processing we refresh PTBAL using the Axium standard process OVERNIGHT_STD_PKG.GENERATE_PTBAL. We also include the TRX database table in our Process to exclude any patients that have an “In-Process” transaction status. This keeps us from locking out any denture or crown patients waiting to pay their balance upon delivery. Our process sets the PATIENT.”Office2” =‘BALOD’.
Managing Record Locks • Insurance Locks • Allow verification of coverage before treating patient • Allow pre-certification of ADA procedure codes required by some insurance payers • Once coverage is verified patient account is unlocked for the day. Then evening process relocks the record based on presence of insurance (database view POLICY.”Company”) • We are primarily concerned about patients with insurance were our school accepts insurance assignment as payment in-full
In Conclusion • This has been a small taste of what we do with custom processes at the University of Tennessee. • Affordable consulting on custom Oracle programming and custom Crystal Reports is available. • Further details about any of the processes presented are available by contacting me, Frank Pancratz, at fpancratz@utmem.edu
Contact Information: Frank Pancratz, fpancraz@utmem.edu University of Tennessee, College of Dentistry (Memphis) (901) 488-9059 Questions?