Closed Amy-Xu closed 6 years ago
@MaxGhenis Thanks for this detailed feedback (& proofreading!!). Let me go through them one by one.
The number of beneficiaries/recipients/enrollees (I'd pick one term) is taken from the CPS as-is. The totals don't exactly match MEPS and targets, but some of those differences are explained by the institutionalized population.
Originally I thought beneficiary refers to enrollee who actually receives benefits, and enrollee refers to eligibles who actually enroll in the programs. But could't find any support to that. So need to dig in the CMS glossary to see which one is the best, or probably they're all the same.
On Thu, 3 May 2018, Amy Xu wrote:
@MaxGhenis Thanks for this detailed feedback (& proofreading!!). Let me go through them one by one.
The number of beneficiaries/recipients/enrollees (I'd pick one term) is taken from the CPS as-is. The totals don't exactly match MEPS and targets, but some of those differences are explained by the institutionalized population.
The insurance value is the same for any eligible family, weather or not they are enrolled or receive benefits. If they became sick, they would be enrolled, so we should attribute the insurance value (perhaps modified to their personal circumstances) to them as a transfer.
Here at Cambridge hospital (next door to where I live), each new patient is checked for insurance eligibility, and if eligible but unenrolled is enrolled on the spot. There is no difference in treatment, only an extra hour in the finance department.
Dan
Originally I thought beneficiary refers to enrollee who actually receives benefits, and enrollee refers to eligibles who actually enroll in the programs. But could't find any support to that. So need to dig in the CMS glossary to see which one is the best, or probably they're all the same.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.[AHvQVbfhZiNJqNkOU7S2UHYGq4ru7svtks5tu0O3gaJpZM4TjlY0.gif]
@Amy-Xu before you spend time going through my many comments (sorry about that), could you address this point? Might save some time if MEPS matching is unnecessary.
Also: how does this process relate to the changes making these programs based on insurance value? I thought all beneficiaries basically get the same values under that logic; if so, what's the value of matching to MEPS?
@MaxGhenis
how does this process relate to the changes making these programs based on insurance value?
I think we define insurance value (at least to this point) as average matched expenditure. We match each enrollee in CPS a expenditure from MEPS, and then calculate the average by income group. .
We match each enrollee in CPS a expenditure from MEPS, and then calculate the average by income group.
Where in this documentation is that specified? Also this is in flux based on https://github.com/open-source-economics/taxdata/pull/185 right? If that discussion lands on not stratifying by income group, then this documentation will be out of date, and the MEPS matching will be entirely unnecessary: benefit values will be a constant defined as the administrative total divided by the CPS beneficiary count.
Where in this documentation is that specified?
It's not mentioned in this documentation, but I explained that assumption in the general documentation, medicare and medicaid section.
Also this is in flux based on open-source-economics/taxdata#185 right?
Yep.
If that discussion lands on not stratifying by income group, then this documentation will be out of date, and the MEPS matching will be entirely unnecessary: benefit values will be a constant defined as the administrative total divided by the CPS beneficiary count.
If we end up using the new definition of insurance value for UBI, I think we could do that in taxdata repo. We can still keep this imputation in C-TAM, since the imputations are not solely prepared for UBI studies.
Thanks @Amy-Xu, makes sense that this describes the current routine which estimates costs rather than insurance value.
If we end up using the new definition of insurance value for UBI, I think we could do that in taxdata repo. We can still keep this imputation in C-TAM, since the imputations are not solely prepared for UBI studies.
Where would the transformation to insurance value be documented?
@Amy-Xu said:
If we end up using the new definition of insurance value for UBI, I think we could do that in taxdata repo.
I think this is a very bad idea. We need to figure out how to impute the government cost (or actuarial value) of health insurance via Medicare and via Medicaid. My understanding is that in the research literature and in DC practice (at CBO and TPC, for example) the total annual cost of Medicare is divided by the number of enrollees (regardless of whether or not they have any Medicare claims during the year) and that single actuarial value of the insurance is assigned to each Medicare enrollee. And the same procedure is done for Medicaid.
Remember, or look at Tax-Calculator/TaxBrain if you haven't done that lately, the CPS benefits variables are used to compute the Government Cost of each benefit. The value of benefits to individuals (that is, the "insurance value" or "consumption value" of benefits) is calculated separately using benefit-related consumption parameters. If you aren't familiar with these parameters, read the user documentation.
If somebody can point to research papers or DC practice that imputes the actuarial value (not the "insurance value") of benefits in a way that is different than what I describe above, then point us all to that literature so we can evaluate it. Otherwise, in each year, every Medicare enrollee will have the same value for the Medicare benefits variable and every Medicaid enrollee will have the same value for the Medicaid benefits variable.
@MattHJensen @feenberg @Amy-Xu @MaxGhenis @andersonfrailey
@martinholmer I do agree that using the same actuarial value for everyone seems to be the best at the moment.
I think this is a very bad idea.
Do you mean assigning those values in taxdata is a very bad idea? Or you mean keeping this MEPS imputation in C-TAM is a very bad idea?
@Amy-Xu asked:
Do you mean assigning those values in taxdata is a very bad idea? Or you mean keeping this MEPS imputation in C-TAM is a very bad idea?
I mean assigning the MEPS medical expenditure values to cps_benefits.csv.gz
is a bad idea.
How do the MEPS medical expenditure data heandle the administrative costs of Medicare and Medicaid?
How do the MEPS medical expenditure data handle that Medicare and Medicaid do not always pay the whole medical expense because of deductibles and co-insurance?
@MattHJensen
@martinholmer
I mean assigning the MEPS medical expenditure values to cps_benefits.csv.gz is a bad idea.
I agree. That happened by accident. After Max pointed it out in issue https://github.com/open-source-economics/C-TAM/issues/68, I asked Anderson to open https://github.com/open-source-economics/taxdata/pull/185 to replace the MEPS expenditure values. Now it seems everyone agrees in #71 that a uniform actuarial value should be assigned to all enrollees, which I can highlight to Anderson in PR 185 shortly. Do you think it is problematic to implement the assignment in taxdata?
@Amy-Xu asked:
Now it seems everyone agrees in #71 that a uniform actuarial value should be assigned to all enrollees, which I can highlight to Anderson in PR 185 shortly. Do you think it is problematic to implement the assignment in taxdata?
Depends on the answers to the two questions I asked before:
If the administrative costs are not included in the MEPS expenditures, then taxdata cannot prepare the medical benefits data in the same way as all the other benefits are handled (that is, the filing units' benefit amounts add up to total program cost including program administrative cost).
If the MEPS medical expenditure data include expenditures that Medicare and Medicaid do not reimburse (because of deductibles and co-insurance), then the MEPS medical expenditure data overstate program cost.
So, if there is a problem with either question, it wound seem as if things would need to be corrected back in the C-TAM repository. Does that make sense?
@MattHJensen @andersonfrailey
Thanks Martin. @martinholmer
Remember, or look at Tax-Calculator/TaxBrain if you haven't done that lately, the CPS benefits variables are used to compute the Government Cost of each benefit.
My understanding is that whatever Tax-Calculator or TaxBrain could do depends on what has been modeled and imputed in C-TAM. By this point, I don't think administrative cost for any program has been included. Thus at this moment, 'Government Cost' doesn't seem accurate per se. What we have been using in the paper is 'Benefit payments.' Maybe something along that line is better.
cc @MattHJensen
If the administrative costs are not included in the MEPS expenditures, then taxdata cannot prepare the medical benefits data in the same way as all the other benefits are handled (that is, the filing units' benefit amounts add up to total program cost including program administrative cost).
As I described above, it doesn't seem administrative cost is very relevant in this decision.
If the MEPS medical expenditure data include expenditures that Medicare and Medicaid do not reimburse (because of deductibles and co-insurance), then the MEPS medical expenditure data overstate program cost.
MEPS provides payment data by source, which I understand as the bill covered by Medicare or Medicaid. Is that right? Most of the reports I've read so far suggest MEPS underreports the expenditure.
@Amy-Xu said about C-TAM data:
By this point, I don't think administrative cost for any program has been included.
If that's the goal, there are a couple of problems.
First, when benefit programs are repealed in Tax-Calculator, the budgetary savings is going to be understated because the administrative cost savings will not be accounted for. Is that OK for add-UBI-and-repeal-benefits-programs analysis?
Second, your statement (that administrative costs are not included in any benefits) is just not true, and therefore, the different types of benefits are inconsistent with respect to whether or not they include the administrative costs of providing the benefits. The clearest example of where benefits include administrative costs is TANF. Just a couple of weeks ago, you merged pull request #67 which increased aggregate TANF benefits from about $9.6 billion to about $29.3 billion. The old target of 9.6 was what HHS calls TOTAL EXPENDITURES ON ASSISTANCE and the new target add to the 9.6 the TOTAL EXPENDITURES ON NON-ASSISTANCE. But the NON-ASSISTANCE includes about $2.3 billion in "Administration" and "Systems", which seem clearly to be administrative costs. The 2.3 is roughly 8 percent of the total. Here is the screen shot of the page that the TANF/README.md files points to as the source of TANF data.
And, I imagine if I looked at veterans benefits, I'd find that the administrative cost of running the VA hospital system is included. Or did you factor out those administrative costs?
@martinholmer thanks for doing the research on TANF and emphasizing the importance of administrative costs for UBI analysis, which I agree with and asked about in https://github.com/open-source-economics/C-TAM/issues/60. I think any UBI analysis needs both, since administrative costs should not be included in each tax unit's welfare benefit of current programs but the overhead's budgetary impact can be spread out. Since this issue spans beyond Medicaid and Medicare do you want to continue the discussion there?
That said the VA hospital administration seems like a tricky one, since hospital administration is part of any hospital. If they got cash instead and spent it on private medical insurance, they'd probably still be paying hospital administration fees in some way. This is quite different than, say, TANF or SNAP overhead.
Separately, how is MEPS relevant if Medicaid and Medicare are calculated just as administrative total divided by CPS beneficiaries? I thought MEPS was only used for matching.
@Amy-Xu said about C-TAM medical benefits data:
MEPS provides payment data by source, which I understand as the bill covered by Medicare or Medicaid. Is that right? Most of the reports I've read so far suggest MEPS underreports the expenditure.
After looking at the two notebooks in the "C-TAM/Medicare and Medicaid" directory and reading the MEPS codebook, I see that the MEPS variables being used are program-reimbursed amounts, and therefore, don't include out-of-pocket expenditures by the individual to meet deductibles and co-insurance.
However, the MEPS amounts are not the amounts used for benefits in the taxdata/Tax-Calculator CPS files. The raw MEPS amounts have been scaled up so that the aggregates meet some kind of target, which is not documented.
Here is what's done to the MEPS amounts at the end of the notebook that prepares Medicare benefits:
I don't understand statement [77]: the comment or the statement. Can you explain? Where does the target come from? Why is the target in the comment different from the target in the statement? Why is the denominator of ratio
different from the value in Out [76]? And most importantly, does the target include the administrative costs of operating the Medicare program?
Here is what's done to the MEPS amounts at the end of the notebook that prepares Medicaid benefits:
I don't understand where any of the numbers used in the first statement below come from.
Medicaid_total_noninstitutional = 468.00 - 18.10 - 116.20 * 45 / 77
ratio = Medicaid_total_noninstitutional/Matched_total
CPS["MedicaidX"] = np.zeros(len(CPS))
CPS.MedicaidX = CPS.TOTMCD14 * ratio
And because there is no documentation on this, I have no idea whether this variable includes administrative costs. Can you explain?
Thanks for the discussion here. @martinholmer @MaxGhenis
Before digging into the questions brought up here, I want to see whether we have consensus on the following issues:
We can do the assignment of actuarial values for Medicaid and Medicare in taxdata, because the calculation is merely one scaler per year.
The general logic of this MEPS imputation is not completely trash and thus can stay in this repo, as long as well-documented.
I have been almost the only reviewer for this repo for roughly two years, so I'm always happy to see more people get involved and check my work. As I was the only one, inevitably there're a number of issues slipped through my hands. Thanks for pointing them out and I will address them carefully.
@martinholmer said
@Amy-Xu said about C-TAM data:
By this point, I don't think administrative cost for any program has been included.
If that's the goal, there are a couple of problems.
First, when benefit programs are repealed in Tax-Calculator, the budgetary savings is going to be understated because the administrative cost savings will not be accounted for. Is that OK for add-UBI-and-repeal-benefits-programs analysis?
Administrative cost not being included in C-TAM is not the goal. C-TAM is a project under development. It is outlined in the README of this repo that adding administrative cost, along with imputing institutional population, is something we want to do in near future. I do agree that both benefit expenditure and administrative cost should be included.
Yes, the total cost is understated because administrative cost has not been included, which we acknowledged in the caveat section in our previous paper. That being said, thinking about the ratio of admin cost to total cost, I assume the understatement is relatively modest. In the meantime, we probably should add a note for TC/TaxBrain users, acknowledge this deficiency and give them a heads up that we will fix it.
@martinholmer
However, the MEPS amounts are not the amounts used for benefits in the taxdata/Tax-Calculator CPS files. The raw MEPS amounts have been scaled up so that the aggregates meet some kind of target, which is not documented.
I went back to the notebooks and realized the ones in C-TAM master was outdated. Just pushed my local version to this branch. I know there're still some hard-coded numbers. I'll change them in a sec. The documentation for targets are included at page 54 in the general documentation. I copied the section here.
On Fri, 18 May 2018, Amy Xu wrote:
@Amy-Xu commented on this pull request.
In Medicare and Medicaid/README.md:
+## Benefit + +The amount of benefit is very pertinent to individual???s health condition, age, close to death, incom e etc. But information like how close to death is not observable, and some other information like hea lth condition is available in MEPS but not so in CPS. Therefore, we made a compromise with the match and only execute the matching procedure based on variables available in both datasets. In current rou tine, we used age, gender, census region and income to match MEPS beneficiary to CPS. + +Specifically, for each CPS beneficiary, we find a pool of donors from MEPS defined by following stan dards: + +- age within plus or minus 2 range +- same gender +- same census region +- income within plus or minus 100 range + +Then we use a random number generator to pick one donor from the pool defined above, and assign this donor???s benefit amount to the corresponding CPS beneficiary. This set of standards work well for the vast majority of beneficiaries in CPS. However there???re several scenarios the method doesn???t work. F irst, CPS has beneficiaries older than 85, but the max age in MEPS is 85. Thus all 85 or older CPS me dicare/medicaid beneficiary share the same group of donor from MEPS who are labeled at 85 years old. Second, certain age range of donors in MEPS don???t have income fell in the given range. Current routin e use the donor with closest income in the given age range. + +This matching routine assumes the matched CPS benefits replicate the MEPS distribution in terms of i ncome, age, gender, and census region. However, the aggregate benefit at this point is still well-bel ow official spending of the year. In 2014 Medicare Trustee report, benefit expense is about 604 billi
Do the CPS benefits replicate the aggregates calculated from MEPS? If not, perhaps the distribution of age, gender, income and region differs in the CPS from MEPS. CPS is probably better. Does aggregate benefit in MEPS match administrative totals? If not, perhaps MEPS isn't perfect. We should be able to tell which of these is the case. Is there another possibility? I don't have an idea of how to fix either problem, though.
dan
Merging this PR in at the end of this week if no one raises any concern.