Thursday, March 26, 2015

Cost-shifting vs cross-subsidization

Medicare pays less. If you have private insurance, that might be good for you.
It has been interesting to watch all the different reactions to Austin Frakt's piece on so-called "cost-shifting." For the uninitiated, cost-shifting refers to the hypothesis that low Medicare payment rates causes providers to shift the cost of treating Medicare patients onto privately insured patients through higher prices.

I think it might help here to distinguish two separate things: the "cost-shifting" hypothesis can be either a values claim or a causal claim. As Frakt repeatedly noted in his NYT post as well as on TIE, there's plenty of evidence that providers do cross-subsidize by charging different prices to different types of customers. As a values statement, you could certainly interpret this as meaning that higher margin patients, such as those with private insurance, "bear" a larger share of the provider's fixed costs than lower margin Medicare patients, because they represent a larger share of the provider's revenue. But that's extremely different than the causal claim that lower payment rates for Medicare cause providers to increase prices to private insurers.

The causal claim version of the cost-shifting hypothesis is not supported by either economic theory or empirical evidence. Consider the theory: we'll let [$]P_m[$] denote the rates paid to Medicare and [$]P_i[$] be the rates to private insurers, while [$]m[$] is the number of Medicare patients and [$]y[$] is the number of privately insured patients that the hospital treats. The function [$]c\left(m+y\right)[$] gives the hospital's total costs of treating all their patients. We'll assume that the government controls [$]P_m[$] and sets it below market rates so that [$]P_m \lt P_i[$]. Demand for healthcare depends in part on price, so [$]y[$] is actually a function of [$]P_i,[$] and we'll denote this demand function as [$]y=f\left(P_i\right)[$]. We can, of course, write a similar function for Medicare but since the government sets [$]P_m[$], we'll leave that implicit for our purposes. The hospital chooses [$]P_i[$] and [$]m[$]--the number of medicare patients it will accept--to maximize profits [$]\pi[$] given by [$$]\max_{P_i,m}\pi=P_mm+P_if\left(P_i\right)-c\left(m+f\left(P_i\right)\right).[$$] The first order conditions are
\begin{align}
P_i:&~f\left(P_i\right)+P_if'\left(P_i\right) =c'\left(m+f\left(P_i\right)\right)f'\left(P_i\right) \\
m:&~P_m=c'\left(m+f\left(P_i\right)\right)
\end{align}
where [$]f'\left(P_i\right)[$] is the first derivative of [$]f\left(P_i\right)[$] while [$]c'\left(m+f\left(P_i\right)\right)[$], the first derivative of [$]c\left(m+f\left(P_i\right)\right)[$], is the marginal cost function. Combining the two FOCs we get
\begin{equation}
f\left(P_i\right)=\left(P_m-P_i\right)f'\left(P_i\right) \label{intuit}
\end{equation}
Totally differentiating, we get
\begin{equation}
\frac{\partial P_i}{\partial P_m}=\frac{f'\left(P_i\right)}{2f'\left(P_i\right)-f''\left(P_i\right)\left(P_m-P_i\right)}
\end{equation}
Ok, for a standard demand curve, [$]f'\left(P_i\right)<0[$] and we postulated that [$]P_m-P_i<0[$]. Off the top of my head I don't recall any theorems about the second derivative of demand [$]f''\left(P_i\right)[$] but I will argue it is negative, because we typically think of people wanting infinite--or at least disproportionately large quantities--of something when its price is zero, which doesn't happen if the second derivative is positive (assuming twice continuous differentiability, etc). Hence, [$]\frac{\partial P_i}{\partial P_m}>0[$] which means this theory predicts that a decrease in Medicare payment rates will actually cause hospitals to decrease prices to private insurers as well. (Did I do all the math right? Some one please check me.)

We can intuit this result by examining equation \eqref{intuit} and recalling that [$]y=f\left(P_i\right)[$]. A decrease in [$]P_m[$] increases the right-hand side of the equation, implying an increase in [$]y[$], and we know the only way to increase [$]y[$] is by decreasing the price [$]P_i[$]. That is, hospitals seek to offset lost revenues from Medicare patients by serving fewer Medicare patients and enticing more privately insured patients with lower prices.

Austin Frakt has already gone through the evidence, and in fact confirms exactly what this little theory predicted: lower Medicare rates decrease rather than increase prices to private insurers.

Tuesday, March 24, 2015

What is a "broad-based tax cut?"

In honor of tax season, I want to talk about an old pet peeve of mine: when people say "broad-based tax cut" or "across-the-board tax cut." Pretty much every presidential election year, some GOP candidate proposes an "across-the-board" tax rate cut--last time it was Mitt Romney--by which they mean a reduction in the marginal tax rates at all tax brackets, and the press usually reports this as "something for everyone," as though cuts in lower rates go to lower income groups, while cuts in higher brackets go to higher income brackets. That presentation is only half true: while only the highest income earners benefit from a cut in the top marginal tax rate, cuts in rates for lower brackets are actually shared by both lower income earners and those in the highest income bracket.

In general, those in the highest tax bracket always benefit the most from tax cuts in any tax bracket.

I'll refer you to Chye-Ching Huang for an explainer on why exactly that is the case, but to illustrate the point, I've made an app which lets you see how the money from various kinds of tax cuts (or hikes) is distributed across income groups. The table below the graph gives all of the maximum income thresholds for each Federal Income Tax bracket, with the corresponding tax rate to the right. Using the up/down arrows next to each, you can change any of the income thresholds or tax rates, including the standard deduction. The graph then shows how much more or less each income group would pay in taxes as a result of your policy, compared to the actual 2014 rates. I have started you out with a $50 increase in the standard deduction versus actual 2014 rates:

Tax Rates

ThresholdRate
$907510%
$3690015%
$8935025%
$18635028%
$40510030%
$40675035%
over$40675039.6%
standard deduction$6200

Show original Rates
ThresholdRate
$907510%
$3690015%
$8935025%
$18635028%
$40510030%
$40675035%
over$40675039.6%
standard deduction$6200

Wednesday, March 11, 2015

A fix for Google Chart API

I've been working with Google Chart recently, and while it makes some pretty cool graphics, there are some things that bug me about it. Here's one: there's no method for adding a series to the graph. Considering the following graph, which grabs and plots data from FRED based on user input:

If you press the button it adds the PCE Deflator to the series that was already there. This is pretty common functionality for a web chart. But Google Chart does it poorly.


There are two ways to plot series in google chart: either use addRows or setCell. Here's how it works with addRows: Suppose you've just done your ajax or whatever so you now have a javascript array of dates and an array of corresponding values for the series you want to graph. The Google chart only reads data from Google's DataTable class object, so you need to reorganize your data from whatever came over via ajax into a DataTable using the DataTable's interface, consisting of the addRows and setCell methods. So for example we can do this:
var temp=[];
for(var i=0;i<dates.length;i++){
  temp.push(new Date([dates[i]),parseFloat(values[i])]);
}
var data=new google.visualization.DataTable();
data.addColumn('date','X');
data.addColumn('number','Series Name');
data.addRows(temp);
Importantly, addRows will only accept a vector of rows of data as an argument. If your ajax data source forces you to loop through the rows of data anyway (this is true of the FRED API, for example), and you want to graph all your series at once, then this is fine. But you've already graphed one series, and want to add a second, then you can't use addRows. So you have use setCell instead, and consequently have to keep track of row and column numbers manually:
if(data.getNumberOfRows()!=values.length){
data.addRows(values.length);
}
data.addColumn('number','Second Series');
for(var i=0;i<values.length;i++){
    data.setCell(i,1,parseFloat(values[i]));
}
Either way, because Google's chart objects always interpret rows as observations and columns as series, you are forced to iterate through each row of the DataTable to add a series. I don't think this makes any sense--for a graphing application, you want to focus on adding and manipulating whole series--adding columns at a time, not rows. I'd count this oversight as a bug.

To fix this bug, I've made a small extension of the Google API: a method addColumnWithValues, which takes three arguments, data type, series name, and an array of all the values. So to add a series you simply do:
data.addColumnWithValues('number','Series 2',values);
No more typing out for loops or manually tracking all the row and column numbers. To use my extension, you'll need to drop this in your javascript code somewhere inside the callback for the google chart:
google.visualization.DataTable.prototype.addColumnWithValues=function(type,name,valuesarray){
var that=this;
that.addColumn(type,name);
var rowNum=valuesarray.length;
var colNum=that.getNumberOfColumns()-1;
if(colNum===0){
that.addRows(rowNum);
}
switch(type){
case 'number':
for(var i=0;i<rowNum;i++){
that.setCell(i,colNum,parseFloat(valuesarray[i]));
}
break;
case 'date':
for(var i=0;i<rowNum;i++){
that.setCell(i,colNum,new Date(valuesarray[i]));
}
break;
default:
for(var i=0;i<rowNum;i++){
that.setCell(i,colNum,valuesarray[i]);
}
break;
}
}
Would it have been so hard for Google to include something like this in the original API? I think they should have.

Note that this is not necessarily a high-performance solution. It's something of a hack really, that works because javascript is extremely dynamically typed. While this solution works, I suspect Google could get a lot better performance building something up from the lower levels of the DataTable class, avoiding the need to call the setCell method for literally each row of data. In particular, I suspect if they changed the DataTable class so that it stored data as an array of column-arrays instead of an array of row-arrays, almost everything would be faster, and most things would require less coding.

I don't think there's much doubt that Google's charts are prettier, but if you want easy line graphs you are always welcome to use my own homegrown javascript graph API--a graphing engine for the HTML5 <canvas> element--which I've used on this blog previously.

Update: I did a speed test comparing google's API with my own canvas graph API. Regardless of the format of the raw data (in column arrays vs FRED-like json objects), my API is about 2 orders of magnitude faster than google chart.

Hierarchy of American law

Several news stories have led me to believe Americans don't really understand that American law has a fairly strict order of precedence. A state can't overturn a federal law. The president--nor even Congress--can't overturn a ratified treaty.

As a refresher, this is the order of precedence:
  1. US Constitution
  2. Treaties
  3. Federal statute
  4. Federal regulations
  5. Federal caselaw
  6. State Constitutions
  7. other state laws
An authority lower on this list cannot overrule any authority higher on this list unless explicitly authorized to do so by something even higher on the list. Treaties are actually one of the highest forms of American law, and the only legal way out of a treaty obligation is to negotiate and ratify another treaty (well, I suppose a constitutional amendment is another option). Violations of treaties tend to have relatively minor consequences so we do it often, but make no mistake--that is totally illegal.

Also, you'll note I did not rank city, township, and county laws and regulations on the list. That's because, from the perspective of the US constitution, none of those exist. The US constitution creates states (and the District of Columbia), and all other local laws and regulations are expressions of the powers it delegates to the states.

Monday, March 9, 2015

Obamacare and "health inflation"

The term "healthcare inflation" is one that makes my skin crawl--an increase in relative prices is not inflation!--but nevertheless a major talking point about healthcare reform. Chris Conover has a piece criticizing Obamacare supporters for prematurely crediting the ACA with reducing--argh--healthcare inflation.

Conover has a pretty good point. For all the bluster, healthcare prices actually track the general price level in the economy pretty well, and so with the disinflation caused by the Great Recession, we've seen a corresponding decrease in the rate of price increases in the healthcare sector. Which is to say, much of the decrease in growth in health prices has been a decrease in inflation, rather than the decrease in relative prices that supporters of the ACA boast.

Conover offered a version of this graph, but I felt it was unfairly missing the 0-axis in his version:
"Excess" healthcare price increases, measured as the difference between year-over-year increases in healthcare prices and year-over-year increases in overall price level.
You can see that the trajectory after the Great Recession has been pretty erratic. After the trough but before the ACA, there was an explosion in the relative prices of healthcare, and after the ACA the "excess inflation" in healthcare essentially vanished--for roughly the past four years, the relative price of healthcare hasn't risen at all.

Like Conover, I'm reluctant to credit the ACA for this. I've always felt that the cost-control provisions of the ACA were pretty weak, and that other aspects of the law--such as expanding health coverage and boosting demand--were likely to increase healthcare prices further, so that significant reductions in health price increases were unlikely. And any quarter now, we could see the line in that graph spike back up, like it did throughout the 1995-2010 period. But here's the point that Conover misses: if that spike doesn't happen, then years from now it will be very hard not to credit the ACA for that change. In fact, we did have a characteristic price spike after the recession and before the ACA that could suggest it wasn't the recession that caused the change.