ROCK STAR EPIC REFUND INTERFACE PROCESS VIA PS 9.2 AP MODULE (IN/OUT BOUND INTERFACES) SESSION Wed, Jun 15, 2016 (08:30 AM - 09:30 AM)

Size: px
Start display at page:

Download "ROCK STAR EPIC REFUND INTERFACE PROCESS VIA PS 9.2 AP MODULE (IN/OUT BOUND INTERFACES) SESSION Wed, Jun 15, 2016 (08:30 AM - 09:30 AM)"

Transcription

1 ROCK STAR EPIC REFUND INTERFACE PROCESS VIA PS 9.2 AP MODULE (IN/OUT BOUND INTERFACES) SESSION Wed, Jun 15, 2016 (08:30 AM - 09:30 AM)

2 PRESENTERS Stacey Harris Sr Systems Analyst Seattle Cancer Care Alliance Randy Johnson Managing Director SpearMC Lesia Aragon Financial Systems Manager Seattle Cancer Care Alliance

3 Seattle Cancer Care Alliance brings together the leading research teams and cancer specialists from Fred Hutch, Seattle Children s and UW Medicine in the pursuit of better, longer, richer lives for our patients.

4 ABOUT SPEARMC World Class PeopleSoft Financials and Supply Chain Management Consultants

5

6

7

8

9

10 SEATTLE CANCER CARE ALLIANCE & SPEARMC PeopleSoft FSCM 9.2 (PeopleTools 8.54)

11 OVERVIEW Seattle Cancer Care Alliance is a specialty cancer hospital with three partners: Fred Hutchinson Seattle Children s University of Washington Medicine, including UWP/CUMG Physicians Seattle Cancer Care Alliance utilizes the Epic Hospital Resolute Billing system for inpatient, outpatient, institutional and research refunds Upon a reimplementation/update to PeopleSoft FMS 9.2, SCCA created interfaces to automate the refund process: Inbound refund interface from Epic to PeopleSoft Outbound payment information interface from PeopleSoft to Epic Future desire is for this reconciliation to be handled in Epic so that we can remove all patient sensitive information from PeopleSoft FMS.

12 DISCUSSION SECTION 1 Prior State 1 SECTION 3 Technical 3 SECTION 2 Requirements 2 SECTION 4 Current State 4

13 SECTION 1 PRIOR STATE Old workflow prior to Epic interfaces

14 PRIOR STATE Completely paper and manual process (processed 2000 to 2500 refunds per year) Multiple hands offs On average, touched by six people prior to the check going out the door Struggled with lost check requests and duplicate refunds Unpredictable turn-around times for checks Manually entering same information into different systems Manually entered voucher in PeopleSoft FSCM Manually entered check information in Epic Resolute Hospital Billing Hard copy refund paperwork storage in two departments

15 PRIOR STATE

16 SECTION 2 REQUIREMENTS Requirements necessary for the PeopleSoft voucher build, Epic updating and critical internal control points within the process

17 REQUIREMENTS Desired Weekly Epic file with detail to automatically generate vouchers Only approved Epic refund transactions Refund by check only Refund details must be readily reportable out of PS Create Epic control report to identify the refund detail to coincide with the file provided by Epic Detail should be at the HAR level and aggregate as one payment at the Payee and Address level PS will create outbound file after check run containing: HAR# paid, check number, check date, amount, transaction ID, and payee name Delivered All desired requirements with one exception: Unable to roll up refund requests by payee and address. Individual refund requests sent causing separate checks to be created for every refund request

18 EPIC SUPPLIER SET UP STUMBLING BLOCKS Epic did not have a location where the PS supplier ID could be stored Epic could not provide us with anything that uniquely identified the payee Name and address match did not suffice for individuals: How do we handle two people who live at the same address and have the same name? (Alex = Alexander, Alexandria or Jr/Sr at same address) No address consistency for corporate payees. Epic uses an address override option for the majority of refund payments due to different remit address requirements. All possible addresses would need to be created in PS in order to find the supplier. Lots of maintenance and no provision for typos or format differences without address cleansing software in Epic or PS.

19 REQUIREMENTS- SUPPLIER SET DILEMMA Payee> Regular Supplier Payee>One Time Supplier Payee> Single Payment Supplier Con- Risk of assigning multiple payees to same supplier ID. PS not provided supplier ID nor a strong identifier for supplier lookup Con- Minimal amount of suppliers re-used, still creating a large number of suppliers Pro-Easily track each payee to supplier detailed data through delivered functionality such as supplier lists and statistics Con-Single supplier could have multiple addresses with no specific trend to denote use. Pro- Creates unique supplier per refund so no risk of assigning multiple payees to same supplier ID Con- Create supplier for each refund generating multiple suppliers Pro- Supplier is automatically inactivated Con- Upon a refund void and reissue; the appropriate supplier record must be reactivated Pro- Creates unique payee name and address. Methodology recommended by other hospitals Pro- Less data fields to populate Con- Only one supplier used so cannot report by Supplier ID. Mitigation- Still have ability to report on payee name & address. Small voucher page customization added visibility to payee name Pro- No need to continually update supplier addresses or create a matching routine to find appropriate address to use

20 White board our flow of data and common definitions and understanding

21 SECTION 3 TECHNICAL Receive weekly refund request file from Epic Resolute Hospital Billing then respond back after refund pay cycle with payment information

22 PROGRAM FLOW DIAGRAM PS Epic Refund Voucher and Payment Processing Epic Refund Request File PS Epic Voucher File Import Process Voucher Build Pull Epic Refund Request File Validation, Translation & Error Processing Load to PS Voucher Staging Tables Validation & Error Processing Load to PS Voucher Tables Post Vouchers Run Refund Paycycle Post Payments PS Epic Refund Payment Export Epic Refund Payment File

23 GENERAL INFORMATION Files are received in the early morning and payments are processed later same day. The payment file schedule is held when extra time is needed to process the payments. The extract files are transmitted through a secure FTP servers to protect sensitive data (patient and financial data). The FTP servers look for files throughout the scheduled day so some flexibility is built into the schedule. Patient information is included in the file for refund activity that is reconciled in the PeopleSoft FMS GL module instead of Epic. The file import program creates a patient record (MRN) in PS for the refund reconciliation process and it is also used with patient deposits. Patient information is provided in both the refund request file and the Epic daily journal import file.

24 VOUCHER BUILD PRE-EDIT ERRORS Pre-edit errors prohibit the transaction from being processed by voucher edit processing. For example, if the transaction has an invalid supplier ID, the voucher edit subprocess cannot process default values correctly, because supplier ID is part of the PeopleSoft Payables control hierarchy. The following general conditions result in preedit errors: Invalid business unit. Invalid supplier. No default location for supplier. Blank invoice ID, and auto-assign option is not selected on the run control page. No invoice date, and auto-assign option is not selected on the run control page. Invalid supplier location (if specified). Invalid supplier address (if specified). Invalid voucher origin (if specified). No association of purchase order or receiver lines with voucher lines, and distribution information is absent. No voucher line information.

25 CUSTOM APPLICATION ENGINE (AE) PROGRAMS PeopleSoft Application Engine (AE) program Import Program Modeled based on the delivered GL_JRNL_IMP program and the generated AE code for File Layout Definitions Used fixed file layout to avoid reported issues with comma or pipe delimited files Epic file utility had difficulty processing a file with a complex hierarchy so we created a couple staging records to simplify Voucher staging tables used, note single payment required staging tables* VCHR_HDR_STG VCHR_VNDR_STG* VCHR_PYMT_STG VCHR_BANK_STG* VCHR_LINE_STG VCHR_DIST_STG

26 FILES MANAGED BY CALLED POWERSHELL SCRIPT AE programs execute PowerShell scripts in order to retrieve and process the incoming files and send the outgoing files. Tip: Need to commit work before the Exec or command will fail /* Get input files, concatenate, copy to archive */ &ScriptName = "d:\ps\custom\scripts\sccaapvchrepic.ps1"; &CommandLine = "powershell -file " &ScriptName; &LogFile.WriteLine("****CommandLine " &CommandLine); /* Need to commit work or Exec will fail */ CommitWork(); &ExitCode = Exec(&CommandLine, %Exec_Synchronous + %FilePath_Absolute); If &ExitCode <> 0 Then MessageBox(0, "", 0, 0, ("Script was not Successful! Exit code returned by script was " &ExitCode)); Else MessageBox(0, "", 0, 0, ("Script to retrieve and archive files was Successful!")); &ImportFile = GetFile("intfc\AP\scca_apvchr_epic.txt", "r", "a", %FilePath_Relative);

27 SINGLE PAYMENT SUPPLIER CONFIGURATION One single payment supplier ID (hard coded into program) Unique Pay Group = ER & Payment Method = CHK

28 VOUCHER CONFIGURATION Voucher Source and Batch Interface = CUST activated Oracle supplied value Voucher Origin = EPR selected Pre-Approved for Workflow Approval Voucher Style = SGLP this voucher style produces separate checks per voucher

29 VOUCHER PAGE CUSTOMIZATION When the Voucher Style is SinglePay (SGLP), the Single Payment Supplier Name (PS_VCHR_VNDR_INFO table) will display in the Supplier Name Search Results column rather than the actual Supplier Name

30 REFUND PAY CYCLE All Pay Cycles check Use Supplier Pay Group Supplier Pay Group = ER

31 PAYMENT SELECTION CRITERIA

32 PAYMENT RESPONSE FILE

33 SECTION 4 CURRENT STATE New Automated Workflow

34 SUMMARY - EPIC REFUND DATA FLOW TO AP & GL Both patient refunds and insurance refunds are classified as Personal/Family so brought in AR code to indicate patient, insurance, institutional, or research refund types

35 INTERNAL CONTROL

36 INTERNAL CONTROL Example of data we export out of PeopleSoft and match to Epic reporting for internal control purposes

37 DEDICATED PAY CYCLE AND PAY GROUP

38 DEDICATED TRIAL REGISTER

39 EPIC NOTES Patient Refund Identified as Self-Pay Hospital Account Number Check Number Date Amount Payee Address Override: Street Number City State Zip All Other Payees Identified by Financial Class Hospital Account Number Check Number Date Amount Payee Address Override: Street Number City State Zip

40 EPIC REFUND WORKFLOW

41 SUMMARY Few manual hands off and only three people involved in process (50% reduction) Experiencing higher refund volumes (4000+ or two-fold) but no additional resources required to handle volume Soft copy refund paperwork storage within Epic. No hard copies stored Consistent turn time for refunds, improved accuracy and a predictable process No concerns with multiple checks going to the same insurance company

42 CONCLUDING THOUGHTS ANY QUESTIONS?

43 PRESENTERS Stacey Harris Sr Systems Analyst Seattle Cancer Care Alliance Randy Johnson Managing Director SpearMC Lesia Aragon Financial Systems Manager Seattle Cancer Care Alliance

44 THANK YOU!