1. Data Warehouse User Group February 24, 2011  Recent RVU Updates in Warehouse

2. 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

3. 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

4. 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”

5. 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.

6. 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.

7. 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 YrMod1 = "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”

8. 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.625 66 – surgical team 76 – repeat proc/same doc 77 – repeat proc/different doc.75 78 – return to or 79 – unrelated proc/same doc/postop 80 – assistant surgeon 81 – minimum assistant surgeon.16 82 -- 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!

9. 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.625 66 or 'ST' – surgical team 76 or 'RPSD' – repeat proc/same doc 77 or 'RPDD' – repeat proc/different doc.75 78 or 'RTO' – return to or 79 or 'UPSD' – unrelated proc/same doc/postop 80 or 'ASURG' – assistant surgeon 81 or 'MAS' – minimum assistant surgeon.16 82 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

10. RVUs in the Data Warehouse – what happened? mult = 50%mult = 62.5%mult = 75%mult = 16% Post CYMod1=MPMod1=TWOMod1=RTOMod1=USPDMod1=ASNRMod1=ASURG 2001406622713101116 200234849661286111 200331545592116619 200437147761711229 20057641079519165109 2006834637912202168 200797211211662144374 200814231551702482311 20091410661862265305 201018379817529189792 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:

11. RVUs in the Data Warehouse – values Before and After Before the Update After the Update – values are now correct

12. 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.

13. 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 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 https://www.cms.gov/apps/physician-fee-schedule/documentation.aspx 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

14. 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 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

15. Upcoming Cognos Training Next Cognos 7.4 Training scheduled for March 22 nd and 23 rd (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/d wh/training.aspx https://www.intranet.medschool.ucsf.edu/medgroup/private/d wh/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.

16. 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.

17. 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 = (CASE WHEN @mod1 = '51' THEN.50 -- Multi Procs WHEN @mod1 = '54' THEN.885 -- Surg Care Only WHEN @mod1 = '55' THEN.13 -- Post-Op Mgt Only WHEN @mod1 = '56' THEN.11-- Pre-Op Mgt Only WHEN @mod1 IN ('62','66') THEN.625-- Surg Team WHEN @mod1 IN ('76','77','78','79') THEN.75-- Repeat Procs and Return to OR WHEN @mod1 IN ('80','81','82') THEN.16--Assist Surg ELSE 1.00 END) * (CASE WHEN @mod1 IN ('GC','50','RT','LT') THEN-- Resident Part/Bilat Proc/Right Side/Left Side CASE WHEN @mod2 = '51' THEN.50 -- Multi Procs WHEN @mod2 = '54' THEN.885 -- Surg Care Only WHEN @mod2 = '55' THEN.13 -- Post-Op Mgt Only WHEN @mod2 = '56' THEN.11 -- Pre-Op Mgt Only WHEN @mod2 IN ('62','66') THEN.625 -- Surg Team WHEN @mod2 IN ('76','77','78','79') THEN.75 -- Repeat Procs and Return to OR WHEN @mod2 IN ('80','81','82') THEN.16 --Assist Surg ELSE 1.00 END ELSE 1.00 END) RETURN @temp_mult END

18. 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 = (CASE WHEN @mod1 IN('51', 'MP') THEN.50 -- Multi Procs WHEN @mod1 IN('54', 'SCO') THEN.885 -- Surg Care Only WHEN @mod1 IN('55', 'PMO') THEN.13 -- Post-Op Mgt Only WHEN @mod1 IN('56', 'PRMO') THEN.11-- Pre-Op Mgt Only WHEN @mod1 IN('62', 'TWO', '66', 'ST') THEN.625-- Surg Team WHEN @mod1 IN('76', 'RPSD', '77','RPDD', '78', 'RTO', '79', 'UPSD' ) THEN.75 -- Repeat Procs and Return to OR WHEN @mod1 IN('80', 'ASURG', '81', 'MAS', '82', 'ASNR') THEN.16--Assist Surg ELSE 1.00 END) * (CASE WHEN @mod1 IN ('GC', 'RES', '50', 'BIL', 'RT', 'RSB', 'LT', 'LS') THEN-- Resident Part/Bilat Proc/Right Side/Left Side CASE WHEN @mod1 IN('51', 'MP') THEN.50 -- Multi Procs WHEN @mod1 IN('54', 'SCO') THEN.885 -- Surg Care Only WHEN @mod1 IN('55', 'PMO') THEN.13 -- Post-Op Mgt Only WHEN @mod1 IN('56', 'PRMO') THEN.11-- Pre-Op Mgt Only WHEN @mod1 IN('62', 'TWO', '66', 'ST') THEN.625-- Surg Team WHEN @mod1 IN('76', 'RPSD', '77','RPDD', '78', 'RTO', '79', 'UPSD' ) THEN.75 -- Repeat Procs and Return to OR WHEN @mod1 IN('80', 'ASURG', '81', 'MAS', '82', 'ASNR') THEN.16 --Assist Surg ELSE 1.00 END ELSE 1.00 END) RETURN @temp_mult END