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
BAR Group -------->
(DN200)
Division -------->
(DN102)
Cost Center/DBS Number -------->
(DN202, Report Category 1)
PSA Department -------->
(Cost Center to PSA Mapping from
Finance)
Billing Provider/Service Provider -------->
(DN3)
Place of Service -------->
(DN100, Medicare Place of Service)
FSC Category -------->
(DN19, Report Category 2)
APEX
Billing Agent
<-------- Billing Agent
(DEP Master File, Grouper 6)
Division
<-------- Division
(DEP Master File, Grouper 7)
Cost Center
<-------- Cost Center/DBS Number
(DEP Master File, Grouper 1)
PSA Dept
Provider/Serv Prov
<-------- PSA Department
(Cost Center to PSA Mapping from
Finance)
<-------- Billing Provider/Service Provider
(SER Master File)
POS
<-------- Place of Service
(EAF Master File, POS Code)
Plan Category
<-------- Payer/Plan Category
(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 Charityrelated 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



Payors





320+ with activity in Apex to date
Ex: Anthem BX/BS, CCS-CA, Cigna
Plans


19 categories currently
Ex: Aetna, Blue Cross, Medicare
1050+ 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, MediCal 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 drillthru 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 (REP0018607)
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:
http://learningcenter.ucsfmedicalcenter.org/
Preparing for Apex cubes and
packages…online training
2) From there, you’ll be
shown all classes
related to your choices
1) After logging in,
menus will guide you to
find courses based on
area and function
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?