Data Warehouse User Group February 24, 2011

1. Data Warehouse User GroupFebruary 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 • 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 • 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: 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? • 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 • 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

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

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