FBCS Patch 34 Overview

1. FBCS Patch 34Overview • Compatible with: PRC*5.1*162, FB*3.5*132, GEC*2*35

2. Patch 34Overview • Prerequisite Installations • Primary Purpose • Summary of Patch 34 Enhancement Changes • Batch Functionality • Reset Tool • Summary of Patch 34 Defect Repairs • Preparing for the install • Questions and Answers

3. Prerequisite installations Required Builds: • DSIF*3.2*23 • PRC*5.1*162 • FB*3.5*132 • GEC*2*35

4. Purpose The primary objective ofPatch 34: Prevent VistA Fee duplicate Internal Control Number (ICN) payments. A duplicate ICN payment is defined as a single payment line in the VistA Fee database that is transmitted more than once to Central Fee, with each transmission potentially resulting in a different payment to the payee (Non-VA provider or Veteran)

5. FBCS Complimentary Changes • Incorporates the VistA changes related to new batch status and reject flag automation into FBCS. • Re-designs Finalization flow and interface to accommodate new functionality

6. New Functionality • Automatically communicates Central Fee rejects via new Payment Batch Result Message • Automatically updates batch status in VistA Fee • Automatically flags CF identified rejects in VistA Fee (update batch/invoice) • Requires new Security Keys for local reject identification and batch finalization

7. New Functionality • Allows Identification of local rejects prior to or during batch finalization only • Prevents finalization of batch more than once • Automatically communicates local rejects to Central Fee & replace 994 code sheets with new Voucher Batch Message

8. New Functionality • Automatically communicates receipt of Voucher Batch Message via Voucher Batch Acknowledgement Message • Allows Re-initialization of rejects only when batch has a status of VOUCHERED and a Voucher Batch Message Acknowledgement Status is not pending or error

9. New Functionality • Automatically communicates post finalization rejects via Post Voucher Reject Message • Automatically flags post finalization rejects in VistA Fee (update batch/invoice) • Provide new Central Fee reports to assist in the process

10. Automatically transmitted From Central Fee to VistA Fee when TRANSMITTED batch was received and reviewed by Central Fee • Identifies Central Fee accepted and rejected payments • Automatically causes an update to the VistA Fee batch status • All lines rejected – VOUCHERED • All lines accepted – CENTRAL FEE ACCEPTED • Some lines accepted & some lines rejected – CENTRAL FEE ACCEPTED

11. Automatically Updated To VOUCHERED • When all lines are rejected by Central Fee • Can be found under Finalized & Austin Rejects view • Will not have a Voucher Ack Status • Will show Completed by “POSTMASTER”

12. Automatically Updated to CENTRAL FEE ACCEPTED

13. New Security Keys • Users must hold the new FBAAREJECT key to flag/identify local rejects. • Users must hold the new FBAAFINANCE key to finalize a batch. *Local reject identification and finalization process is combined in FBCS. If the user must flag/identify local rejects during the finalization process, the user must hold the FBAAREJECT and the FBAAFINANCE security keys

14. No Key – No Finalize Button • The Finalize button will not display without the FBAAFINANCE Security Key

15. New Batch Finalization Functionality • Allows finalization of batches with a batch status of CENTRAL FEE ACCEPTED only • Informs VistA Fee what happened to the payments in the batch that were transmitted to Central Fee • Informs VistA Fee what has been rejected • Automatically generates the Voucher Batch Message • Automatically updates Voucher Message Acknowledgment Status in VistA Fee to Pending • Lines are NOT re-initiated at this time * Transmitted batches after install of these patches cannot be finalized anymore.

16. Finalizing A Central Fee Accepted Batch in FBCS • Review Central Fee rejects • Select the batch and click the Finalize Button. • If no rejects are present or if no rejects will be identified Click “Ok” to proceed • If rejects are present or need to be identified review & update the reject information as appropriate & click “OK” to proceed • Two new columns identifying ‘Reject By’ and ‘Reject Reason(s)’ will assist in new Reject Process • Any individual Central Fee rejects will be outlined automatically in the Finalize window. • If applicable, flag an locally identified rejects • Per usual, the batch status will update to “Finalized” (VOUCHERED)

17. Re-Design of Finalize Batch Window

18. Finalizing a Batch with CF Rejects • Review the rejected lines & returned reasons taking note that the “Keep” checkbox is unchecked and in-editable. • Click “OK” to proceed and finalize the batch

19. Central Fee Accepted with Rejects

20. CF Reject Reasons

21. Annotating Local Rejects * NOTE: Users will need the new security key FBAA REJECT in order to process local rejects.

22. Voucher Message Acknowledgment Status

23. Automatically transmitted From VistA Fee to Central FEE when batch is Finalized (VOUCHERED) in VistA Fee • Automatically communicates locally flagged rejects • Automatically instruct Central Fee to release the remainder of the batch (all kept payments) to downstream payment systems (FMS) • Replaces the 994 code sheets

24. Modified Central Fee Process • Automatically receive and review Voucher Batch Message • Automatically delete locally flagged rejects • Release kept payments to downstream payment systems (FMS) • Automatically communicate post voucher rejects

25. Automatically transmitted From Central Fee to VistA Fee when VOUCHERED batch was received, reviewed released for payment by Central Fee • Automatically updates Voucher Message Acknowledgment Status in VistA Fee • Accepted – Confirms successful receipt of locally flagged rejects, kept payments and batch total • Error – Confirms unsuccessful receipt of locally flagged rejects, kept payments and batch total

26. Voucher Ack Status: A

27. Finalized In VistA vs. FBCS • FBCS will not know about the rejects • The Rejects Pending status will be blank X

28. Re-Initiating Rejected Lines • To re-initiate rejected lines, select the batch from the Finalized Batch listing (acknowledgement status must not be pending or error) • Click the Re-initiate button • Click OK at the prompt indicating the number of rejected lines that were once in the selected batch confirming your desire to re-initiate them. • In the pop up window confirm the FCP and Obligation selection and click OK. • Click Yes to view a list of reinitiated items • Click Close when finished with list • Click OK at the prompt indicating the reinitiate was completed successfully into the new batch • The rejected lines, are placed into the newly created batch and can be worked, per usual, in FBCS.

29. Re-Initiating Rejected Lines

30. Re-Initiating Rejected Lines • After clicking ‘Yes’ the user is prompted to select an FCP/Obligation:

31. Re-Initiating Rejected Lines • If you would like to review the re-initiated lines, click Yes when prompted.

32. Re-Initiating Rejected Lines Claim Type Line Number (position) Original Invoice Number Patient Control Number Date of Service Service (HCPCS/CPT) Reject Reason(s) Reject Code(s) Old Batch # No PHI – Can be copied & pasted into alternate programs such as email.

33. Re-Initiating Rejected Lines • Upon successfully re-initiating the lines, the user will be notified.

34. Post VOUCHERED Rejects • It is possible for new/additional rejects to be identified by Central Fee and/or FMS after the batch has been VOUCHERED. • This isneeded in the event there were rejects that need to be re-initiated after Central Fee was instructed to release the batch for payment (Post Voucher Rejects). • When this occurs Central Fee will send a communication to VistA Fee that will update the Rejects Pending from No to Yes for the original batch. • The same Re-initiate process will apply to these batches/rejects • Central Fee Report 12016 (POST-VOUCHER REJECTS) should be utilized to identify these

35. Batch Status is Not Automatically Updated to Central Fee Accepted The Reprocess Overdue Batch buttonis used to reset the status of the batch when the batch is not updated to Central Fee Accepted (or Vouchered). If you would like to reset the batch, choose it from the Transmitted list and select ‘Retransmit Batch’ in this window. Note: This should only be done after contacting Central Fee.

36. What if Central Fee Accepted Status isn’t received. When selected, “Retransmit Batch” will update the following data: • BATCH STATUS changed to SUPERVISOR CLOSED • DATE TRANSMITTED is deleted • RETRANSMIT BY is set • RETRANSMIT DATE is set • Queue Data for Transmission option is run to transmit pending batches to Central Fee • Batch status is changed to TRANSMITTED and DATE TRANSMITTED is populated.

37. What if Central Fee Accepted Status isn’t received. Alternatively you may choose to Reprocess an Overdue Batch by rejecting all line items in the original batch and re-initiating them into a new batch. If you would like to reject the entire batch at this stage, choose the batch from the Transmitted list, click Reprocess Overdue Batch and select ‘Reject Batch’ in this window. * This action can only be taken if it’s been two business days since the batch was transmitted

38. What if Central Fee Accepted Status isn’t received. When ‘Reject Batch’ is selected, the following data is updated: • All line items in batch are flagged as locally rejected with reject reason “Rejected by Reprocess Overdue Batch” • 1358 obligation is updated • PAYMENT LINE COUNT is updated • TOTAL DOLLARS is updated • BATCH STATUS changed to VOUCHERED • DATE FINALIZED is set • PERSON WHO COMPLETED is set • TRANSMITTED BATCH WAS REJECTED is set to YES

39. What if Central Fee Accepted Status isn’t received. If Rejecting the Entire Batch note the following will occur: • Re-initiate Rejected Payment items to move the line items into a new open batch • The new batch should be different • Batch is closed • Batch is released by Fee Supervisor • Per standard procedures transmit batches to Central Fee • Central Fee will identify any duplicates and remove them • A Central Fee Accepted status is expected shortly after

40. What if the Acknowledgement isn’t received? In the event that Central Fee does not communicate that they have received your batch or VistA does not intercept this communication, meaning that the Voucher Acknowledgement status fails to update from Pending (P) to Acknowledged (A) you may Retransmit the VoucherMessage • This action can be taken on the third business day after the original voucher message sent date. • Note: If the Voucher Ack Status is (E) Error, the Retransmit Voucher Message option can be used immediately.

41. What if the Acknowledgement isn’t received? The following data is updated when Retransmitting the Voucher Message: • VOUCHER ACK STATUS is changed to (P) Pending • The Voucher Message Date field is changed to the current date

42. Summary of Patch 34 New Process • Open, Close, Release & Transmit Batch per usual • Central Fee generates a Payment Batch Result message • Batch Status is updated to Central Fee Accepted or Vouchered (if all lines were rejected) • 1358 & Batch totals are updated • Finalize the Batch (new FBAAFINANCE key is needed) and identify local rejects, if present. (New FBAAREJECT key would be needed)

43. Summary of Patch 34 New Process • Voucher Batch Message is sent to Central Fee • Central Fee processes batch and newly identified rejects. • Central Fee Acknowledges Receipt and updates Ack Status to (A) ACKNOWLEDGED • If Original batches contained rejects, re-initiate the rejects into a new batch *If the Central Fee Accepted status is not obtained you can Re-Send (Re-Transmit) the batch *If the Ack Status doesn’t update to Acknowledged you can Re-Transmit Voucher message.

44. Patch 34 Enhancements Reset tool

45. Enhancements – Reset Tool Utility to reset/clean “Orphan Claims” due to: • Misapplication of FBCS procedures for claims to remain in an “In Payment” status. • Failure to move from a status of “In Payment” to “Accepted” resulting in the claim continuing to age. • Because of dual processing in VistA & FBCS • Due to improperly preparing the claim before moving to the Payment module. • The claim becomes inaccessible or unable to be prepared and paid correctly.

46. Enhancements – Reset Tool • FBCS will introduce a tool designed to make these “Orphan Claims” accessible once again. • This is done by clearing all previously associated payment data appended to the claim, including invoice and batch details. • This, in turn, will “reset” the claim to a state where it can be retrieved in the FBCS Payment claims bucket. • From this vantage point users can return the claim to D&P or move forward for payment, or identify the claim or lines as already paid through STANDARD FBCS PROCEDURES

47. Enhancements – Reset Tool • Only supervisors will have access to this reset tool but can assign claims to clerks. • Users must take great caution in the use of this tool. • This tool does not update or collect payment information from VistA • This tool clears all previously collected payment data • If some or all lines on the claim have been paid, users may identify this via D&P or to obtain the actual payment data from VistA use the current process of identifying duplicates via the Work Area • Take caution to not make duplicate payments • ALWAYS research claims that are reset to determine if they are already paid • Remember in order for FBCS Payment to identify a previously paid line the veteran, vendor , date and procedure code must match EXACTLY

48. Reset Tool

49. Reset Tool • The selected claims will be reset and all previous payment data will be removed

50. Reset Tool • Claims that have been reset will appear as underlined in the selected user’s claim queue