Some tax units have extremely high values of Medicaid and Medicare

[MaxGhenis]

The maximum benefit amount per person is $455k for Medicaid and $692k for Medicare (notebook). These are somewhat outliers but multiple percent have benefit values in excess of $20k.

Is this expected? Reading through the updated C-TAM documentation I wonder if this has to do with using the Medical Expenditure Panel Survey, where some slices might have high medical expenditure. But is using per-person expenditures an appropriate estimate of the value? In lieu of these programs most people would pay for health insurance, not bear the treatment costs themselves.

cc @Amy-Xu

[MaxGhenis]

vet_ben and other_ben also have some extreme values, maxing out at $140k and $163k, respectively. Ranges for other benefits look more reasonable. From the updated notebook which includes all benefits and limits the CDFs to participants:

[Amy-Xu]

@MaxGhenis Thanks for pointing this out. I want to take a look at Medicaid and Medicare imputation first before replying here. But in terms of veteran benefits, my guess is that the extreme values are a part of CPS ASEC, because we have only assigned averages to individuals which theoretically should n't create very large values.

[Amy-Xu]

@MaxGhenis You're absolutely right. I checked the MEPS raw data, in which max amount paid by Medicare is 459k and max paid by Medicaid is 180k. As we augment Medicare total by 1.46 and Medicaid total by 2.32, I wouldn't be surprised by the two max values you got in the CPS tax unit dataset. Those two indeed seem very large, but given the MEPS raw data statistics and the portion of extreme values, it doesn't seem like a problem to me.

PS: I need to find you the original source, but I remember papers saying MEPS does not have good data on the high cost cases, which possibly means the actual cap could be even higher.

[Amy-Xu]

@MaxGhenis Here you go: http://healthcare-economist.com/2011/12/20/meps-vs-nhea/

Partially because severely ill individuals might have a higher attrition rate.

[MaxGhenis]

OK I guess this is more of a philosophical question then, i.e. my comment above:

But is using per-person expenditures an appropriate estimate of the value? In lieu of these programs most people would pay for health insurance, not bear the treatment costs themselves.

For example if one is interested in replacing these programs with UBI, perhaps with a requirement to use it to purchase health insurance as Charles Murray proposes, the value of these programs is really the insurance value. I think in most or all use cases for this data, we're more interested in a tax unit's insurance value of the program, not the high-variance benefit value in that particular year.

Averaging over some strata (maybe age and state, or even just age) would be useful to identify winners and losers of reforms. If the current fields are intended to match raw surveys, could this be represented in new fields?

[feenberg]

In my view the argument using insurance value is totally valid. We want to classify taxpayers by some measure of welfare, and the insurance value is much closer ordinary understanding. dan

…

On Mon, 23 Apr 2018, Max Ghenis wrote: OK I guess this is more of a philosophical question then, i.e. my comment above: But is using per-person expenditures an appropriate estimate of the value? In lieu of these programs most people would pay for health insurance, not bear the treatment costs themselves. For example if one is interested in replacing these programs with UBI, perhaps with a requirement to use it to purchase health insurance as Charles Murray proposes, the value of these programs is really the insurance value. I think in most or all use cases for this data, we're more interested in a tax unit's insurance value of the program, not the high-variance benefit value in that particular year. Averaging over some strata (maybe age and state, or even just age) would be useful to identify winners and losers of reforms. If the current fields are intended to match raw surveys, could this be represented in new fields? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.[AHvQVR3Y_camxjcJaG4uV-HC5b7K9kWsks5trj7lgaJpZM4TO6W2.gif]

[Amy-Xu]

@MaxGhenis

I think in most or all use cases for this data, we're more interested in a tax unit's insurance value of the program, not the high-variance benefit value in that particular year.

Yes, this is what we intended to do, as confirmed by Dan's reply above. In the C-TAM documentation, all the plots are based on the averages by income group, which is our operating definition of insurance value. But I don't think I saved the insurance value in the imputation file, so the tax unit file still use the raw imputation from MEPS. Long story short, looks like you help us found another glitch. Thanks!! Let me see if there's a shortcut to fix it.

[Amy-Xu]

@andersonfrailey Max helped identified another issue I missed. For Medicaid and Medicare, we should have included their insurance value, as shown down below, instead the raw imputed values. Insurance values are computed as raw imputed values averaged by quintile income groups.

In other words, there is supposed to be much less volatility in Medicaid or Medicare. Each Medicaid enrollee should get around 6k 'benefit' and each medicare enrollee 12k. I'm trying to think of an easy way to fix this. One way is to replace any current medicare/medicaid tax unit with a multiple of 6k/12k, and then pin the benefit total to the current level. Of course, the most traditional way would be replacing the medicare and medicaid input files in the tax unit creation process.

What do you think?

[andersonfrailey]

@Amy-Xu, Just to be clear, the new values for Medicare and Medicaid at the tax unit level will be ($12K * number of Medicare recipients) and ($6K * number of Medicaid recipients)?

If so, we could do that in final prep. We keep the imputed Medicare and Medicaid values for everyone in the tax unit so we could just count up how many individuals in each unit have non-zero values and multiply that by $12K/$6K.

and then pin the benefit total to the current level

Could you expand on this? Are you saying we wouldn't extrapolate those two variables?

[Amy-Xu]

Just to be clear, the new values for Medicare and Medicaid at the tax unit level will be ($12K * number of Medicare recipients) and ($6K * number of Medicaid recipients)?

Yep exactly. We want to refer to the tables in the general documentation for specific numbers.

then pin the benefit total to the current level

I imagine the benefit totals should be close to the current Medicare/Medicaid totals, since those values are individual level averages. But the new totals would not be exactly same, because the weights and units are not identical. So if the new total deviates from current total, we can apply a scaler to adjust it.

Good question on extrapolation. I have not thought through it. Any suggestions?

[andersonfrailey]

imagine the benefit totals should be close to the current Medicare/Medicaid totals, since those values are individual level averages. But the new totals would not be exactly same, because the weights and units are not identical. So if the new total deviates from current total, we can apply a scaler to adjust it.

Ah, so when you refer to "total" you're talking about the total for all tax units. So we first assign the new values then apply a scalar to hit our current Medicare and Medicaid values?

Good question on extrapolation. I have not thought through it. Any suggestions?

I'm not familiar with how Medicare and Medicaid benefits values are determined, but I'd image increasing the total for each tax unit at the rate of inflation at least would make sense.

[Amy-Xu]

So we first assign the new values then apply a scalar to hit our current Medicare and Medicaid values?

That's what I was thinking.

[andersonfrailey]

@Amy-Xu, ok. I'll work on a PR to make these changes.

[MaxGhenis]

In this comment @Amy-Xu said:

But in terms of veteran benefits, my guess is that the extreme values are a part of CPS ASEC, because we have only assigned averages to individuals which theoretically should n't create very large values.

Based on what we're seeing with Medicaid and Medicare, do you think this is because veteran benefits are reported as the cost, rather than insurance value of any veterans healthcare? Could something similar be going on with other_ben? If so is there enough data to replace these health costs with insurance values as well?

(I can file a separate issue on those if that's better organizationally.)

[Amy-Xu]

@MaxGhenis

do you think this is because veteran benefits are reported as the cost, rather than insurance value of any veterans healthcare?

Nah, CPS only includes non-medical veteran's benefit and we impute the medical part as overall medical spending divided by total veteran number. So this one is insurance value already.

Could something similar be going on with other_ben?

I don't think so, but Anderson knows other_ben better than I do.

[andersonfrailey]

other_ben is simply the aggregate sum of administration reported costs of programs distributed proportionally to tax units. So an exceptionally high Medicaid value could also lead to an exceptionally high other_ben value.

[MaxGhenis]

CPS only includes non-medical veteran's benefit and we impute the medical part as overall medical spending divided by total veteran number.

In that case do we know why some tax units would have $140k in veteran benefits in a year? Is there a pension-type program that's included in this?

[Amy-Xu]

@MaxGhenis

In that case do we know why some tax units would have $140k in veteran benefits in a year? Is there a pension-type program that's included in this?

I assume so. The first category of expenditure VA outlines is compensation and pension. Even though CPS didn't specify, I think compensation and pension is included.

[feenberg]

I typed "pension retired general" into Google and learned this: A three-star officer with 35 years' experience would get about $169,200 a year, up about $39,000, or 30%. The highest pension, $272,892, is paid to a retired four-star officer with 43 years of service, according to the Pentagon.Feb 3, 2012 but before I accepted this explanation I would want to look at the CPS record for evidence the respondent was plausibly a general. That is, high education and older. Also, I would want to know there were not very many such records in the data. dan

…

On Tue, 1 May 2018, Amy Xu wrote: @MaxGhenis In that case do we know why some tax units would have $140k in veteran benefits in a year? Is there a pension-type program that's included in this? I assume so. The first category of expenditure VA outlines is compensation and pension. Even though CPS didn't specify, I think compensation and pension is included. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.[AHvQVWs_pwwR_3VCTLsL_89fKyJLZCYoks5tuK1CgaJpZM4TO6W2.gif]

[MaxGhenis]

@andersonfrailey said:

other_ben is simply the aggregate sum of administration reported costs of programs distributed proportionally to tax units. So an exceptionally high Medicaid value could also lead to an exceptionally high other_ben value.

Sorry I don't understand this. Are you saying other_ben is a constant share of benefits? RECID 312413 has 60%+ of total income coming from other_ben. I couldn't find documentation on other_ben in the C-TAM doc.

[andersonfrailey]

@MaxGhenis, we determine other_ben by looking at what percent of a subset of benefits a tax unit receives. We take the total value of Medicaid, SSI, SNAP, and Veterans Benefits; determine what percentage of that total each tax unit receives and assign them that percent of the total for other_ben.

Because the programs included in other_ben are taken from reported expenditures on the program, not modeled, all other_ben calculations are done in cps_data/finalprep.py, not C-TAM.

[MaxGhenis]

Thanks @andersonfrailey that makes sense, and it seems like the new Medicaid change improves the estimate of other_ben too. Given VB can be so high due to pensions, which we'd expect would be unrelated to other benefits, would it make sense to drop that and just consider Medicaid, SSI, and SNAP (maybe something like WIC too)? It doesn't look like any of the other_ben programs relate to veterans.

[andersonfrailey]

@MaxGhenis that is a good point. @MattHJensen what are your thoughts on that?

[MattHJensen]

That makes sense to me. cc @Amy-Xu

[MaxGhenis]

Filed PSLmodels/taxdata#277.

[martinholmer]

@Amy-Xu, Can you close resolved C-TAM issue #68? Medicare and Medicaid benefits are now actuarial values of the health insurance and veterans benefits are no longer used to distribute other benefits. I would close the issue, but do not have the privileges to do that in the C-TAM repository. So, you (or somebody else with privileges) need to maintain the C-TAM repository.

@MattHJensen @andersonfrailey @MaxGhenis

[Amy-Xu]

Thanks Martin. Closing.