Data warehouse user group february 24 2011
Download
1 / 18

Data Warehouse User Group February 24, 2011 - PowerPoint PPT Presentation


  • 73 Views
  • Uploaded on

Data Warehouse User Group February 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Data Warehouse User Group February 24, 2011' - ata


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Data warehouse user group february 24 2011

Data Warehouse User GroupFebruary 24, 2011

  • Recent RVU Updates in Warehouse


Rvus in the data warehouse what happened
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 happened1
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


Issues with connect cd
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 cd1
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 cd2
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 cd3
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”


Issues with significant modifiers
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!


Issues with significant modifiers1
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


  • Rvus in the data warehouse what happened2
    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:


    Rvus in the data warehouse values before and after
    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 after1
    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
    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
    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
    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 – 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
    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


    Appendix b sigmod multiplier function revised
    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


    ad