Oregon Health & Science University’s Implementation of Oracle Financials Accounting Hub

Colleen Roden – OHSU SR Oracle Business Analyst Leslie Marti – Impac SR Principal Consultant Janette Lockhart – Impac Technical Manager

About OHSU Schools of Medicine, Dentistry, Nursing and Science & Engineering OHSU Hospital and Doernbecher Children’s Hospital Dozens of primary and specialty care clinics Major Research Institutes Over 200 cash service sites that support the university, hospitals and clinics

About Impac OHSU consulting partner for over 17 years Oracle Platinum Partner since inception Specializations in 7 areas including SOA and BI Real-world expertise in E-Business Suite consulting and implementations

Project Objectives 5

Project Background OHSU was manually reconciling cash deposits and disbursements from source systems to bank statements (Oracle AR, Payroll, Banner & Epic) In 2011 automated reconciliation process for AR, Banner & Payroll with Oracle Cash Management In June 2013 launched project to automate cash reconciliation and accounting for Epic 6

Project Evolution Integrated Epic Hospital and Professional Billing System with Oracle Cash Management leveraging same infrastructure as Banner Interface Enhanced CM interface, adding in cash accounting Developed new interface to GL to record revenue and receivable accounting for Epic 7

Solutions 8

Applications Oracle Financial Accounting Hub as a long term strategy to integrate our 3 rd party systems with Oracle GL: –Epic Hospital and Professional Billing –Banner Student System –Custom Internal Billing System Oracle Cash Management Interfaces & Functionality

Integration Technology SOA Suite predecessors implemented in 2001 – Oracle iHub and 3 rd party products Later, Oracle B2B 10g was introduced for Trading Partner integration In 2012, SOA Suite 11g was implemented for Trading Partner integration Subsequent successful projects

11 SOA Integration Flows for FAH and CM

FAH vs SLA 12

FAH Design – Source Data Understand the source data –Dissect the source data to understand what pieces are available and what logic is needed to create the accounting –Also understand what data isn’t needed. Confidential information was a important factor OHSU had two different patient billing structures but both using EPIC. 13

FAH Design – Applications Two custom applications - Hospital Billing and Professional Billing –Each had different data sets –Segregation of the data was important security requirement –Each had their own accounting groups 14

15 FAH Design – Event Model Event model is the your first step in designing your custom FAH application Within the events model, accounting events are categorized by entity, event class and event type Entity = Transactions. –That was our highest level of data. Every line in EPIC is a transaction. Event Class = Epic had 4 types of transactions. –Patient Charges, Adjustments, Receipts and Cash Deposits. Each Event class had one or more event types.

FAH Design – Event Model 16

Each Event Class had a custom transaction object table and a view. Each is assigned in the accounting events class options form The view may not contain every column in the transaction object table. The columns in the TO tables represent the data we needed from the EPIC transactions. We defined the view based on the data attributes we specifically needed for our Accounting. 17 FAH Design – Transaction Objects

We already had existing custom tables we used to interface external Cash transactions to Cash Mgmt Open Interface for reconciliation We used these tables for our Cash Mgmt(Deposit) transactions. Cash Deposits view it actually looked at these existing cash transactions. 18 FAH Design – Transaction Objects

User Transaction Identifiers are used to show specific data on the actual event when it is created. This is a view that is created and assigned to the accounting Event Class options for each event class This view is not used for any rule creation. You can have 10 UTI defined 19 FAH Design – User Transaction Identifiers

20 FAH Design – Event Class Options UTI View TO View

Journal Line Type: Defines attributes of each JE line (e.g. DR/CR, actual vs budget, transfer to GL in summary/ detail etc.) Account Derivation Rule: Defines type and sequence of rules that will be used to create COA string (e.g. constant value, mapping set, default values) Mapping Set: Map source value to COA Values 21 FAH Design – Journal Entries

Conditions: Conditions can be placed on JLT and ADR priorities to determine when the Line Type or the Rule priority is used by the transaction. Lookup Codes: Are used extensively to define valid values for use in conditions and mapping sets Journal Line Definition: Ties together all the Journal Line Types to make the full accounting entry for a transaction – 22 FAH Design – Journal Entries

23 FAH Design – Journal Line Type Balance Type DR/CR Sign GL Transfer Accounting Class

24 FAH Design – Journal Line Type Condition on Revenue Adjustment Line Type Has to be a DR or CR adjustment not a hospital procedure code and

25 FAH Design – Accounting Definition Rule Revenue Adjustment has a different rule per segment Object Segment Rule uses a mapping set

26 FAH Design – Mapping Set Mapping Set to Map Adjustment Type to Object Source Value COA Values to Adjustment Type Lookup (source data)

27 FAH Design – Journal Line Definition Receivable Revenue for non-hospital procedure code Journal Line Definition for standard adjustment Revenue for hospital procedure code

Application Accounting Definition: Ties together all accounting logic for the full set of transactional data for an application Sub-ledger Accounting Method: Ties together all the AAD for all applications assigned to a ledger. 28 FAH Design – Acct Definitions & Methods

29 FAH Design – App Accounting Definition All Event Classes & Types Application Accounting Definition for Custom Application Journal Definition for Each Event Type

30 FAH Design – Sub-ledger Accounting Method Assign Applications Custom Sub-ledger Accounting Method

31 FAH Design – Sub-ledger Accounting Method Assign Sub-ledger Accounting Method to Ledger

32

33 FAH SOA Integration Characteristics –OHSU Canonical Data Models CDM not used for Transactions – rationale CDM created for Payments –OHSU Common Error Handling Framework –Scheduling handled through E-Business Suite –Custom and seeded Business Events leveraged –Relatively high volumes – 100,000 transactions / day

Lessons Learned Provide paths in setup to deal with exceptions and bad data Develop reports to reconcile to source data and to identify issues (events not create, no accounting) Created process to undo and recreate events to accommodate changes Check for invalid definitions in interface Run Gather Stats on for performance improvements 34

Questions? 35