Data Warehouse User GroupFebruary 24, 2011

Recent RVU Updates in Warehouse

RVUs in the Data Warehouse – what happened?

In a nutshell -- Literal Modifiers Dictionary 5 in IDX: the modifier code dictionary

Each numeric code, including 26 and TC, has a literal/mnemonic counterpart

Apparently, users can enter either one into IDX during charge entry

Supposedly, literals are translated into their numeric equivalents when the HCFA is generated, so that “PRO” actually prints as “26” and “ASURG” prints as “80” (etc.) on the HCFA bill

RVUs in the Data Warehouse – what happened?

Problem: the data warehouse only expected numeric or 2-character modifiers

Literal modifiers impacted us in two unexpected (but important) ways

1. Connect_Cd: determines the actual join to the Medicare Fee Schedules

Join to Med Fee Sched uses (CPT + Connect_Cd)

Connect_Cd values are 0, 26 or TC

2. Significant Modifiers (SigMod): a subset of modifiers used to reduce RVUs in the data warehouse

In general, mimics Medicare's strategy Same algorithm used to calculate RBRVS in the

PSA; unchanged since 2001

Issues with Connect_Cd

This is calculated at the time the transaction (charge) records are extracted from IDX

Basic Logic: If Mod1 or Mod2 or Mod3 or Mod4 = “TC” then

“TC” Else If Mod1 or Mod2 or Mod3 or Mod4 = “26”

then “26” Else default to “0”

PROBLEM: literal modifiers “PRO” and “TECH” were being ignored and the Modifier defaulted to “0”

Issues with Connect_Cd Impact on RVUs was varied

Very few “TECH” or “TC” modified codes billed in IDX, so no significant impact there

Medicare CPT records with both a “26” and “0” modifier entry tend to share the same Work RVU value (see below), so that Work RVU was inadvertently correct most of the time.

Unfortunately, Malpractice, Practice Expense (and so Total RVU) were overstated in these cases.

Issues with Connect_Cd On the other hand, there are codes in the Medicare Fee Schedule

where only the “26” record has any associated RVUs (see below):

In these cases, when Connect_Cd defaulted to “0”, all RVU values, including Work RVU, were undervalued (reported as 0.00)

Conclusion: Connect Code logic led to both over- and under-reporting of RVUs.

Issues with Connect_Cd While entries of the literal modifier “PRO” constituted a small

percentage of overall “26” codes, the numbers jumped in 2008 and have been rising since:

Post Yr Mod1 = "26" Mod1 = "PRO"

2001 229,979 697

2002 254,984 632

2003 273,655 601

2004 291,160 371

2005 309,915 357

2006 364,435 345

2007 409,348 823

2008 410,294 2,297

2009 422,750 3,216

2010 409,409 3,688

2011 48,829 188

Not sure what happened here or why…

Note: the extract script has since been rewritten to treat “PRO” like “26” and “TECH” like “TC”

Issues with Significant Modifiers

Once the correct RVU record has been identified and its values stored with the charge record in the Transaction table (PDS_TXN), a secondary pass is made to the charge lines to determine whether RVUs should be further modified. We refer to these in the warehouse as “Significant Modifiers” or “Sigmods.”

if Mod1 is: RVUs are muliplied by:

51 – multiple procedures .5

54 – surgical care only .885

55 – post operative mgmt only .13

56 – pre-operative mgmt only .11

62 – two surgeons .62566 – surgical team

76 – repeat proc/same doc77 – repeat proc/different doc .7578 – return to or79 – unrelated proc/same doc/postop

80 – assistant surgeon81 – minimum assistant surgeon .1682 -- assistant surgeon/no resident

Also, if Mod1 is 50 (bilateral procedure), LT (left side of body), RT (right side of body) or GC (resident participation) AND Mod2 is one of the codes in the list above, the same multipliers will be applied to the RVUs as are shown above.

PROBLEM: Each one of the numeric codes, as well as 50, LT, RT and GC, has a corresponding literal!

Issues with Significant Modifiers

REVISED list of “Significant Modifiers” or “Sigmods” now reads:

if Mod1 is: RVUs are muliplied by:

51 or 'MP' – multiple procedures .5

54 or 'SCO' – surgical care only .885

55 or 'PMO' – post operative mgmt only .13

56 or 'PRMO' – pre-operative mgmt only .11

62 or 'TWO' – two surgeons .62566 or 'ST' – surgical team

76 or 'RPSD' – repeat proc/same doc77 or 'RPDD' – repeat proc/different doc .7578 or 'RTO' – return to or79 or 'UPSD' – unrelated proc/same doc/postop

80 or 'ASURG' – assistant surgeon81 or 'MAS' – minimum assistant surgeon .1682 or 'ASNR' – assistant surgeon/no resident

Also, if Mod1 is 50 or 'BIL' (bilateral procedure), LT or 'LS' (left side of body), RT or 'RSB' (right side of body) GC or 'RES' (resident participation)

AND Mod2 is one of the codes in the list above, the same multipliers will be applied to the RVUs as are shown above.

NOTE: Revised modifier logic has been incorporated into the warehouse calculation and the RVUs have been updated

RVUs in the Data Warehouse – what happened?

mult = 50%mult =

62.5%mult = 75% mult = 16%

Post CY Mod1=MP Mod1=TWOMod1=RT

OMod1=USP

DMod1=ASNR Mod1=ASURG

2001 406 62 27 13 101 116

2002 348 49 66 12 86 111

2003 315 45 59 21 166 19

2004 371 47 76 17 112 29

2005 764 107 95 19 165 109

2006 834 63 79 12 202 168

2007 972 112 116 62 144 374

2008 1423 155 170 24 82 311

2009 1410 66 186 22 65 305

2010 1837 98 175 29 189 792

Brought to our attention last year by an analyst in Medicine, but the presence and impact of literals appeared to be insignificant (remember: some RVUs went up and some down)

More recently, when Surgery compared Work RVUs in the Util cube to Work RVUs in the Comb_Util cube (source is the processed PSA file), the PSA Work RVUs were significantly lower.

Why was the PSA not impacted?The literal codes were translated into their numeric counterparts before being sent to the PSA analyst to calculate RVUs and RBRVS. That code was written years ago and never touched.

Two main codes caused much of the difference: ‘MP’ and ‘ASURG’

Presence of literals has grown steadily since 2007:

RVUs in the Data Warehouse – values Before and After

Before the

Update

After the Update

– values are now correct

RVUs in the Data Warehouse – values Before and After

Unfortunately, Sigmod “buckets” are still incorrect

“Normal” (i.e Numeric) modifiers correctly grouped in their Sigmod category

“Literal” modifiers still incorrectly grouped in the “Blank” category

NOTE: we are hesitant to update this dimension (even though it’s incorrect) because we’re not sure what effect (if any) it will have on your .ppx reports.

Misc. Notes about RVUs Warehouse RVUs differ slightly from those in the PSA (i.e. Util cube vs. Comb_Util

cube) Warehouse RVUs are based on DOS PSA RVUs are based on Post Date.

Warehouse RVUs will differ from FPSC RVUs FPSC uses national values, so that it can compare MD performance across the

country Warehouse has always applied GPCI modifiers to its base RVUs (work,

malpractice and practice expense) to arrive at a revised total FPSC *back-fills* RVU values for CPTs where Medicare has provided no RVU

value FPSC looks for a “26” record in every case, whether we sent them a 26 in mod1

or mod2 – they always assume the MD is billing for pro-fees

Don’t Forget, the Medical Group’s website is a good resource for information regarding RVUs, RBRVS and the PSA: https://www.intranet.medschool.ucsf.edu/medgroup/private/dwh/bkgrd_rvu_rbrvs_psa/index.aspx

Obviously, CMS is a good resource for documentation: https://www.cms.gov/apps/physician-fee-schedule/documentation.aspx and

http://www.cms.gov/PhysicianFeeSched/PFSRVF/list.asp#TopOfPage

The 2011 Medicare Fee Schedule has been added to the catalog. In order to see it you will have to download the latest copy from the website

Fee Schedules for all years can be found via Impromptu by going to the PDS Li Pay| Dictionaries folder

Misc. Notes about Modifiers Our modifier strategy mimics Medicare’s, but doesn’t exactly match, for example:

Medicare doesn’t necessarily follow our Connect_Cd logic Medicare considers up to 4 modifiers in its decision to alter payment Medicare will sometimes modify RVUs up (mod51), while we never do

FPSC’s modifier strategy is different from ours as well Follow this link to their “RVU and Modifier Assignment Process”:

https://www.facultypractice.org/cps/rde/xchg/fpsc/hs.xsl/128.htm

The important thing is to be consistent in applying modifiers, and UCSF has applied the same logic since 2001.

NOTE: Exactly *how* this strategy is applied is proprietary

Upcoming Cognos Training Next Cognos 7.4 Training scheduled for March 22nd and

23rd (Tuesday and Wednesday).

Sign up deadline is March 15 Minimum of 3 people needed Last couple of trainings had to be canceled

Latest Training Schedule can always be accessed by clicking on the “training and class information” link from the main data warehouse page, or by going to https://www.intranet.medschool.ucsf.edu/medgroup/private/dwh/training.aspx

This will be one of our last Cognos 7.4 series trainings. We will begin Cognos 8 series trainings later this year. We will talk about this in more detail in future user group meetings.

Next User Group Meeting – early this time

Next User Group Meeting in 2 weeks, March 10

We will be discussing Provider Custom Groupings Dashboard reports currently distributed to the departments

will be taken down to this new level Several departments have provided us with custom

groupings, but most have not

We will also be discussing the FPSC Provider Templates Reported and Imputed CFTE metrics are being looked at very

closely these days, as they now appear in the monthly Dashboard reports

Changes implemented by FPSC require that each provider appear in only one department, so that his/her activity can be seen all together..this may affect what some of you are able to see

Those departments not wanting to create Custom Groupings in the warehouse (see bullet above) may want to default to FPSC Specialty groupings.

Appendix A: SigMod Multiplier Function -- ORIGINAL

CREATE FUNCTION [dbo].[fn_mod1mod2_mult](@mod1 varchar(10), @mod2 varchar(10)) RETURNS numeric (10,3)AS BEGIN DECLARE @temp_mult as numeric(10,3)

SELECT @temp_mult = (CASEWHEN @mod1 = '51' THEN .50 -- Multi ProcsWHEN @mod1 = '54' THEN .885 -- Surg Care Only WHEN @mod1 = '55' THEN .13 -- Post-Op Mgt OnlyWHEN @mod1 = '56' THEN .11 -- Pre-Op Mgt OnlyWHEN @mod1 IN ('62','66') THEN .625 -- Surg TeamWHEN @mod1 IN ('76','77','78','79') THEN .75 -- Repeat Procs and Return to ORWHEN @mod1 IN ('80','81','82') THEN .16 --Assist SurgELSE 1.00END) *

(CASE WHEN @mod1 IN ('GC','50','RT','LT') THEN -- Resident Part/Bilat Proc/Right Side/Left SideCASE

WHEN @mod2 = '51' THEN .50 -- Multi ProcsWHEN @mod2 = '54' THEN .885 -- Surg Care Only WHEN @mod2 = '55' THEN .13 -- Post-Op Mgt OnlyWHEN @mod2 = '56' THEN .11 -- Pre-Op Mgt OnlyWHEN @mod2 IN ('62','66') THEN .625 -- Surg TeamWHEN @mod2 IN ('76','77','78','79') THEN .75 -- Repeat Procs and Return to ORWHEN @mod2 IN ('80','81','82') THEN .16 --Assist SurgELSE 1.00 END

ELSE 1.00END)

RETURN @temp_multEND

Appendix B: SigMod Multiplier Function -- REVISED

CREATE FUNCTION [dbo].[fn_mod1mod2_mult](@mod1 varchar(10), @mod2 varchar(10)) RETURNS numeric (10,3)AS BEGIN DECLARE @temp_mult as numeric(10,3)

SELECT @temp_mult = (CASEWHEN @mod1 IN('51', 'MP') THEN .50 -- Multi ProcsWHEN @mod1 IN('54', 'SCO') THEN .885 -- Surg Care Only WHEN @mod1 IN('55', 'PMO') THEN .13 -- Post-Op Mgt OnlyWHEN @mod1 IN('56', 'PRMO') THEN .11 -- Pre-Op Mgt OnlyWHEN @mod1 IN('62', 'TWO', '66', 'ST') THEN .625 -- Surg TeamWHEN @mod1 IN('76', 'RPSD', '77','RPDD', '78', 'RTO', '79', 'UPSD' ) THEN .75 -- Repeat Procs and Return to ORWHEN @mod1 IN('80', 'ASURG', '81', 'MAS', '82', 'ASNR') THEN .16 --Assist SurgELSE 1.00END) *

(CASE WHEN @mod1 IN ('GC', 'RES', '50', 'BIL', 'RT', 'RSB', 'LT', 'LS') THEN -- Resident Part/Bilat Proc/Right Side/Left Side

CASEWHEN @mod1 IN('51', 'MP') THEN .50 -- Multi ProcsWHEN @mod1 IN('54', 'SCO') THEN .885 -- Surg Care Only WHEN @mod1 IN('55', 'PMO') THEN .13 -- Post-Op Mgt OnlyWHEN @mod1 IN('56', 'PRMO') THEN .11 -- Pre-Op Mgt OnlyWHEN @mod1 IN('62', 'TWO', '66', 'ST') THEN .625 -- Surg TeamWHEN @mod1 IN('76', 'RPSD', '77','RPDD', '78', 'RTO', '79', 'UPSD' ) THEN .75 -- Repeat Procs and Return to ORWHEN @mod1 IN('80', 'ASURG', '81', 'MAS', '82', 'ASNR') THEN .16 --Assist SurgELSE 1.00END

ELSE 1.00END)

RETURN @temp_multEND