Data Warehouse User Group July 26, 2012  Combined PB Transaction cube – DRAFT  Apex PB Transaction cube – DRAFT.

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

Introduction to Ledgers
CHC Financial Check Up How to know if your CHC financials are healthy or in need of resuscitation.
What’s New and “Under Construction “ in Accounting Presented by: Nancy Ross.
Accounting for a Service Business Unit 1.8 The Ledger.
 After the 7 transactions, the ledger looks like Page 105 Figure 4.5. (Show On the White board)  There are 10 accounts in the ledger.  How do you calculate.
A more efficient you. Introducing EmployerAccess Anthem’s easy-to-use online benefits management system Anthem Blue Cross is the trade name of Blue Cross.
Generally Accepted Accounting Principles
Billing for Departmental Users
United Nations University United Nations Development Programme UNU Atlas Implementation Project Atlas Briefing Sessions – Tokyo Mar 2009 Requisitions,
Accounting Fundamentals Dr. Yan Xiong Department of Accountancy CSU Sacramento The lecture notes are primarily based on Reimers (2003). 7/11/03.
Accounting Is Fun! List The Steps In The Accounting Cycle 1.Analyze source documents & record business transactions in a journal 2.Post journal entries.
Collecting and Reporting Accounting Information Design of an effective AIS begins by considering outputs from the system. Outputs of an AIS include: 1.
UR Financials Project Company Level Reporting SIG February 18, 2014.
Check It Out 1. 2 Introductions Instructor and student introductions Module overview.
©2008 TTW Where “Lean” principles are considered common sense and are implemented with a passion! Product Training Sales Invoices.
Statewide Financial System Program 1 AR 215 Creating and Maintaining Receivables AR 215 Creating and Maintaining Receivables Welcome.
Internet Research Finding Free and Fee-based Obituaries Online.
Completing the Accounting Cycle. The Adjustment Process  At the end of a fiscal period, we have to make sure that all our financial statements are 100%
Checking Accounts and Banking Services
Questions & Answers Missing Documents and Incorrect Notification.
Stop Payments, Cancel Advices and Return Resolution Reports.
©2008 TTW Where “Lean” principles are considered common sense and are implemented with a passion! Product Training Cash and Cash Management.
Cuff Account Dashboard
PTA Treasurer Training Pam Grigorian August 20, 2015.
Data Warehouse User Group April 25, 2013  Infrastructure Upgrades  HB wRVU Correction  Apex AR Trends Cube Preview  Training / User Group Meeting Schedules.
Student Activity Training FY15-16 Prepared by: HCISD Accounting Department.
©2008 TTW Where “Lean” principles are considered common sense and are implemented with a passion! Product Training Purchase Invoices.
FINANCIAL AWARENESS Checking & Savings Accounts Lesson 3: Managing a Checking Account – Part 2 Instructor PowerPoint Copyright © 2009, Thinking Media,
Data Warehouse User Group June 23, 2011  Migration from Cognos 7 to Cognos 8.
Fifth Third Bank, Member FDIC. Eisenhower High School September 15, 2013.
© 2015 Fidelity National Title Group a a Know before you close. The New Loan Estimate & Closing Disclosure Explained A look at the different sections of.
What to do for a Financial year end And When to do it.
Accounting Concepts & Rules In this lesson we study different concepts used in accounting which help us make correct accounts.
Data Warehouse User Group June 24, 2010  Upcoming Changes to the Cubes  Additions to the MEIS Catalog.
BANK RECONCILIATION STATEMENTS.
Checking Accounts Money Management Chapter 9 Notes
CHC Financial Check Up Karen J. Kuhn Revenue Cycle Management Consultant.
The Collection Process in Medical Billing Francie Walters Jennifer Randall.
Data Warehouse User Group January 10, 2013  Apex IDX SMS Revenue cube  Development Schedule.
DWH User Group Matching to the PSA Reports Matching to the PSA Reports Transaction Cube Revenue Cube Expense Cube Utilization Cube *New* SMS Charges Cube.
Goals of this Session: Brief discussion on core and web.. What is your mandate? Where are you at? Our “notes” Discuss satisfaction, issues, features still.
Opening a Checking Account. What type of bank will you choose? Skill 1  Types – Commercial Banks – Savings and Loans – Credit Unions  Services – Checking.
Test Taking Tips Test Prep  Preparation for your first test should begin on the first day of class; this includes paying attention.
Professional Fee Funds Flow May 19, PSA Report Principles The Professional Service Agreement (PSA) defines the flow of funds to the department.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 3 1 Software Size Estimation I Material adapted from: Disciplined.
DEFINING the BUSINESS REQUIREMENTS. Introduction OLTP and DW planning is different in term of requirements clarity Planning DW is about solving users’
Data Warehouse User Group June 28, 2012  Transactions in Apex – a first look.
Mystery of Closer Donna Magnuson A/R Consultant. Agenda  Why should I close?  Closing Transactions  Pre-closing Process  Closing  Review of the Reports.
1 FINANCIAL ACCOUNTING Week 2: LECTURE 2. 2 Learning Objectives What are accounts and what is the ledger? Understand the principles of double entry. Understand.
Project Nexus Workgroup Extension of Modification 0434 to permit retrospective updates pre-dating Project Nexus Go Live Date 9 th September 2014.
Copyright 2003 Prentice Hall Publishing Company1 Chapter 7 Sales and Collection Cycle.
Chapter 1 Page ref. Chapter 1 Company File Setup and Maintenance 1.
(American Banking Association)
This was written with the assumption that workbooks would be added. Even if these are not introduced until later, the same basic ideas apply Hopefully.
Banner Year End Processing East Carolina University.
Company File Setup and Maintenance Chapter 6. PAGE REF #CHAPTER 6: Company File Setup and Maintenance SLIDE # 2 2 Objectives Use the EasyStep Interview.
NextGen Trustee GL/Accounting This class will cover NextGen Financial Management for Trustee Offices. We will look at GL accounts, Transactions, Bank Reconciliation,
Company File Setup and Maintenance Chapter 6. PAGE REF #CHAPTER 6: Company Setup SLIDE # 2 2 Objectives Use the EasyStep Interview to setup your company.
RESOURCE 2016 FLEXGEN TRUSTEE PART 1 – VARIOUS TOPICS.
Budget Monitoring - Forecasting Ann Sambrook Education Financial Services EFS.
Preparing for fiscal year end close
College Accounting A Contemporary Approach
Student Activity Training FY16-17
NextGen Trustee General Ledger Accounting
EXPERIENCE ON PREPARING mSCOA FINANCIAL STATEMENTS
Cash and Cash Management
Product Training Purchase Invoices
Utility Billing Balancing the Accounts Receivable
Agenda Agenda Demo of Configuration of Business Processes Q & A
Presentation transcript:

Data Warehouse User Group July 26, 2012  Combined PB Transaction cube – DRAFT  Apex PB Transaction cube – DRAFT

Combined PB Transaction cube APEX data will only be available to query from the Cognos 8 series tools (web-based), NOT Cognos 7 Cube will combine Pro-fee transactions from IDX with transactions from Apex’ Resolute PB application Will contain data beginning Fiscal Year 2012, by Post Date Will be populated through FY 2013, or at least while IDX is still posting (IDX to be decommissioned in April 2013)

Combined PB Transaction cube Attempts an apples-to-apples comparison across the two billing systems Only contains those dimensions that both systems shared, or that we were able to derive cleanly and consistently

Combined PB Transaction cube – mapping strategy Comb PB Transaction Dimension IDX APEX BAR Group >Billing Agent< Billing Agent (DN200) (DEP Master File, Grouper 6) Division >Division< Division (DN102) (DEP Master File, Grouper 7) Cost Center/DBS Number >Cost Center< Cost Center/DBS Number (DN202, Report Category 1) (DEP Master File, Grouper 1) PSA Department >PSA Dept< PSA Department (Cost Center to PSA Mapping from Finance) Billing Provider/Service Provider >Provider/Serv Prov< Billing Provider/Service Provider (DN3) (SER Master File) Place of Service >POS< Place of Service (DN100, Medicare Place of Service) (EAF Master File, POS Code) FSC Category >Plan Category< Payer/Plan Category (DN19, Report Category 2) (EPP Master File, Grouper 6)

Combined PB Transaction cube – common dimensions Dimensions will be very familiar to users already querying cubes from Cognos 8.4 Billing Systems are designated as different sources We tried to maintain the same measures as well

Combined PB Transaction cube – decisions made Since the data elements from IDX and Apex don’t match exactly, we were forced to make several assumptions and decisions regarding the data Billing Agent All McKesson Bar Groups rolled up into one for IDX data There is no Research Billing Agent in APEX, but there is a Research Financial Class. This financial class was used to create an artificial Research Billing Agent rollup for the Apex data

Combined PB Transaction cube – decisions made Plan Category In IDX, all FSCs rolled up to high level FSC Categories In Apex, most plans are mapped to one of our old categories, with a couple of exceptions: Charity Plans – these didn’t exist in IDX. Bad Debt was written off using specific Charity- related pay codes, and the associated FSC type on the Invoice was always Self Pay. Charity Plans in APEX don’t have a grouper 6, so we’ve grouped these under Self Pay in this cube “Unlisted” Plans – still figuring out how to group these. They currently appear under the Unknown category Unknown and Blank categories are also related to Undistributed Transactions (more on this later)

Combined PB Transaction cube – decisions made POS: Medicare Place of Service In IDX, this was populated for every transaction (charges, payments, contractual adjustments, bad debt, etc.) Every transaction for a given invoice shared the same POS as the charge line(s) in that Invoice. In APEX, POS is really only meaningful when looking at Charge lines. Payments and other adjustments have Places of Service like “SBO”; i.e. where the payment was made or posted. Sometimes these make sense, most times the don’t. Wherever we were able to match a payment/debit/credit to a charge, the POS for that charge was inherited. For Undistributed transaction in APEX (Payments, Debits, Payment Reversals, Credit), the POS will be NULL or Unknown in our cube *until* that transaction is matched to a charge. This is true for the combined PB as well as the APEX-only PB cube.

Outstanding Issue #1: Undistributed Payments and Other Transactions Undistributed Payments and Other Transactions All New Transactions, except for Charges, come in as Undistributed – this applies to both Pre-payments, as well as Copayments The only way to know what a payment is actually paying for is to match the payment to a charge. This can happen quickly, but the matching can also occur much later Epic’s posting methodology impacts us both financially and data-wise 1) Financial Implications: when do we call a payment a payment? What happens if a DEP recognizes a $100K payment in July, and then that payment is matched/distributed to a different DEP in August (we have already seen examples of this…smaller dollar amounts, but same concept). This would lead to a -$100K the next month. In this scenario, it might make sense to wait to recognize the revenue/payment until it’s been matched to services rendered Calculation of the monthly PSA reconciliation would be directly affected. This is still under discussion, and would impact some departments more than others We are also currently researching how Apex incorporates this into its AR Calculations.

Outstanding Issue #1: Undistributed Payments and Other Transactions (cont.) 2) Data Implications: Lots of Holes Undistributed Payments (and credits, debits, etc.) aren’t associated with a DOS, Billing Provider, Service Provider, Location where service was provided and many other charge-related pieces of info…it’s like they are free-floating until applied/matched Epic’s explanation is that one payment can be distributed to many different charges for a given Guarantor Account These transactions where no matching to a charge has occurred will have blank/NULL/Unknown values for all the items mentioned above We’re not used to seeing BLANKS in our cubes and tables; remember, in IDX, every transaction inherited Provider, Bill Area, Location, Original FSC, etc. from the Invoice Header record

Outstanding Issue #1: Undistributed Payments and Other Transactions (cont.) 2) Data Implications (continued) Biggest Problem = Attribution New payments are automatically associated to a DEP, and some payments even identify a provider (not many), but when matched, both of those could change! Do we give a Department, Provider, Cost Center, or Location “credit” for something that actually doesn’t belong to them? Proposed Solution in the warehouse: Unless the transaction has been matched to charge, we report those charge-related elements as UNKNOWN. The only exception to this is the DEP, since we have to associate these with something known. Drawbacks to this approach: Some Transactions will never be matched to a charge: credits and debits that are posted to a Guarantor Account don’t have to be matched to specific services Data Mismatch: reports run out of Hyperspace/Clarity may group the data differently than our cubes do.

Outstanding Issue #2: Unknown Insurance Plans Hierarchy for Insurance in Apex is  Financial Class 19 categories currently Ex: Aetna, Blue Cross, Medicare  Payors 320+ with activity in Apex to date Ex: Anthem BX/BS, CCS-CA, Cigna  Plans with activity in Apex to date Ex: AETNA MCARE OPEN PLAN PFFS MCARE (12621), B&T HLTHNET B&G ALT (25267), HILL PHYS MED GRP/SF HLTHNET ALT (25089) Apex reports group financial data by Financial Class and/or Payor, but not Plan We care about Plan (the lowest level of detail) because only Plans roll up to the main “FSC categories” that we’re used to; i.e. Commercial, Contract, Medicare, Medi-Cal, etc.

Outstanding Issue #2: Unknown Insurance Plans (cont.) Assumption: we want to keep reporting by these main Payer Categories (Capitation, Contract, Medicare, Medi- Cal etc.) Big Problem: Payments (as well as debit adjustments, credit adjustments, reversals, etc.) get posted to our system with a Payor, but not a Plan. Knowing the Payor allows us to roll up to Financial Class, but not to FSC/Payer Category! Charges are the only transaction detail type that explicitly contain Plan information Data Warehouse solution: *Derive* a Plan for every new payment, adjustment, reversal, etc. Sound easy, but has proved to be really difficult in practice; the payor on an invoice won’t necessarily match the payor on the charge! When a charge payor is different from the payment payor, we are looking to the patient’s Coverage to help us calculate the most likely Plan to associate with that payment Sometimes a patient’s coverage doesn’t include the payor from the payment invoice at all! Drawbacks to this approach? Until a Payment (or Credit or Debit or Reversal, etc.) is matched back to a charge, the Plan is UNKNOWN to us If the patient’s coverage doesn’t include the insurance payor, the Plan information is forever UKNOWN to us

Combined PB Transaction cube – some things to note Purpose of this cube is to provide continuous reporting, especially important for FY2012, but at a general level Only one cube will be built each month; no mini-cubes per Division Querying this cube should be fast since this cube has few dimensions and very few levels within dimensions The cube will NOT have drill-thru capability Totals in this cube will tie back, by source, to IDX-only cubes (currently being refreshed each month), as well as to our future APEX-only cube More detailed analysis should be done in the existing Transaction cube (for IDX), or the Future Apex Transaction cube Both the “old” as well as the “new” Transaction cubes will always have drill-thru capability You’ll have access to the detail that make up these Transaction cubes via a drill- thru from Analysis Studio. You’ll also be able to query the data independently via Query Studio. There will also be a companion Combined HB cube that will function much in the same way

Where are the other cubes – what’s the holdup? Tackling one subject area at time: financial first Validation – just finding any sources for balancing back to Apex has been challenging Only yesterday we identified a Clarity report that seems to be a good candidate (REP ) Medical Center Finance will be tying back to it every month as well We also need to tie back to our existing, IDX-only cubes Outstanding issues (previous slides) How to report Undistributed Payments How to work with limited Plan-level information

Preparing for Apex cubes and packages…parting thoughts We will be offering a larger “orientation” session (probably in a lecture hall) to familiarize users with these new cube formats. However… Be sure to have some PB training. I cannot even pretend to “teach you Apex PB” in one Cognos training class, much less one demo session All users who sign up for Cognos training will be expected to know at least the basic concepts in Apex; e.g. Master Files, Coverages, Guarantor Accounts, etc. Many online classes and documents are available through the learning center:

Preparing for Apex cubes and packages…online training 1) After logging in, menus will guide you to find courses based on area and function 2) From there, you’ll be shown all classes related to your choices

What’s next? By the end of August, we will likely release Combined PB Transaction cube Apex PB Transaction cube Definite Maybe’s: Combined HB Transaction cube (SMS + Apex HB) Apex Utilization cube Apex Appointments cube A finalized Framework Package for Query Studio won’t be ready until September i.e. the detailed reporting environment you currently have for IDX, where elements are organized neatly into logical folders (dates, patient info, etc.) Prior to the August release of our first cubes, I propose some additional working sessions with this group Gives us a chance to look more closely as transaction detail types in Apex Sample exercises and handouts from Candice and my Clarity training in Wisconsin Opportunity to get your input about things like: What dimensions and levels should be contained in the cubes How should the cubes/packages/folders be named and organized?