If we want to keep using the full_benefit flag (which I undersand why we would), we need to put in place a process for maintaining the claims.ref_mcaid_rac_code table. As it is, there are numerous RAC codes that exist in our Medicaid data that aren't found in this reference table. Most (almost all) of these RAC codes begin with 2 or 3 and are for very nuanced state programs that perhaps DSHS didn't need to include in the reference table that our ref_mcaid_rac_code table is copied from.
I'm wondering if it would make sense to check once or twice per year for RAC codes in the elig and claims data that do not join to our ref_mcaid_rac_code table, and then to reach out to HCA and/or DSHS for information that can be used to add a row to our reference table, with the most critical information being the corresponding bsp_group_cid and full_benefit value (Y or N).
If we want to keep using the full_benefit flag (which I undersand why we would), we need to put in place a process for maintaining the claims.ref_mcaid_rac_code table. As it is, there are numerous RAC codes that exist in our Medicaid data that aren't found in this reference table. Most (almost all) of these RAC codes begin with 2 or 3 and are for very nuanced state programs that perhaps DSHS didn't need to include in the reference table that our ref_mcaid_rac_code table is copied from.
I'm wondering if it would make sense to check once or twice per year for RAC codes in the elig and claims data that do not join to our ref_mcaid_rac_code table, and then to reach out to HCA and/or DSHS for information that can be used to add a row to our reference table, with the most critical information being the corresponding bsp_group_cid and full_benefit value (Y or N).