Zach Mortensen -- The Economics of Healthcare Information Technology

QSI Dividend Analysis

zm — Fri, 08 Jun 2007 02:00:00 GMT

The other day Inga wrote "While as a shareholder a dividend is great, I am wondering why a dividend is being paid at all (and am asking for opinions of you gurus.) In this day and age where every IT company is constantly trying to leapfrog one another with the latest, greatest offering, why not re-invest in your products?"

I replied with the following, from which she kindly posted a summary tonight:

Companies pay dividends for a number of reasons. Two of the foremost are 1. To return retained earnings to shareholders when the company believes that it cannot find a better use for the capital, and 2. To raise the share price if the company thinks its market valuation is too low.

My guess is that QSI's circumstance is the former.

On the issue of investment in product development: A little-understood fact of the software business is that the incremental cost of adding each new feature increases exponentially as a function of software size, while the incremental benefit of each new feature increases at a much slower rate. Software systems eventually reach a point where the incremental cost of a new feature is greater than its incremental benefit, and it therefore makes no sense to "re-invest" in features. I have written about this phenomenon in detail. If QSI has come to the realization that continued software development might not make economic sense, they are smarter than the average software vendor.

You ask: "Does QSI just have that much cash on hand?" Yes, they do. If you read the 2006 10-K, you will note that they had net operating cash flows of $17MM, $21MM, and $30MM in 2004, 2005, and 2006. The balance sheet shows they had $56MM in cash on hand at the end of 2006. They're sitting on a pile of loot, and this dividend of $0.25/share on approximately 27 million outstanding shares -- a total dividend payment of less than $7MM -- will not hurt them. The dividend probably amounts to little more than their expected net increase in cash reserves for 2007.

Having a lot of cash on-hand creates what is called a moral hazard, an unfortunate propensity to make bad decisions when things start going well. People in general tend to compensate for a reduction in risk, in this case thanks to a fat wallet, by increasing their risk tolerance. Conversely, when risks abound we tend to operate more cautiously. So returning excess capital to shareholders may provide the added benefit of stronger incentives for the company management to make better investments with the capital that remains.

With that explanation out of the way, it is interesting to note that recent thinking on dividends is that they are a bit outmoded. Open-market stock repurchases have the same effect of returning capital to shareholders, though indirectly: The company bids up its own shares and rewards the shareholders with a capital gain instead of a cash payment. The question of tax effects can complicate the comparison of these two strategies somewhat, but in the end, stock repurchases are generally a more efficient way to return capital to shareholders.

Perhaps page 48 of the 10-K offers a clue as to why the company chose a dividend instead of a stock repurchase. Two insiders control 19% and 17% of the shares, respectively. Each stands to bank north of $1MM in dividends without the need to sell shares. A stock repurchase may have been considered, but these insiders would have to sell shares to benefit from the price increase that would result. And even if they didn't mind letting go of the shares, they would have to comply with the SEC's insider trading rules. A dividend will allow these insiders a handsome payday without diluting their ownership interests in the company or subjecting them to SEC scrutiny.

Moral Hazard in Healthcare IT

zm — Wed, 21 Mar 2007 15:00:00 GMT

The term moral hazard is generally used within the insurance industry to describe the tendency of the insured to increase their risk tolerance once their risks are hedged by insurance. For example, a consumer with a homeowner's insurance policy might decide against returning home to double-check that she had turned off the stove or locked the door before she left the house. Or a consumer with a comprehensive auto insurance policy might not worry so much about parking his car in a bad neighborhood at night. In general, reducing people's exposure to risk seems to increase their tolerance for risk, and the corresponding increase in risky behavior is what constitutes the moral hazard.

The concept extends to other domains. Professor Kent Smetters of The Wharton School taught that US Department of Transportation rules requiring seat belts and airbags in new vehicles have led to increasingly-reckless driving as drivers have felt more secure. And while driver and passenger fatalities have diminished due to the direct effects of these safety devices in the years since these regulations took effect, fatalities of motorcyclists, bicyclists, and pedestrians have increased proportionately with drivers' reckless behavior during the same time period. Smetters joked that the most effective automobile safety device may not be a seat belt or an airbag, but rather a large dagger mounted on the steering wheel and aimed directly at the driver's heart, as it would give the driver and any pedestrian roughly equal odds of dying in a minor collision!

Recent events in hospitals illustrate how moral hazard applies to healthcare technology:

Three premature babies died at Clarian's Methodist Hospital in Indiana last September after receiving adult doses of heparin instead of the less-potent Hep-Loc to clear their IV lines. A pharmacy tech apparently stocked the wrong medication in the NICU's automated dispensing cabinet. The automated-dispensing technology created the moral hazard in this case: The nurses trusted the cabinet so much that they engaged in the risky behavior of not verifying the medication before administering it. Ironically, this technology that is touted to reduce errors and save lives created a moral hazard that has caused errors and cost lives.

A newborn was abducted from her mother's room at Covenant Lakeside Hospital in Lubbock, TX earlier this month. The infant was apparently tagged with an RFID device that failed to prevent the abduction, unlike a similar device in this earlier case, but the media reports indicate that the device somehow alerted the hospital staff that the baby was being taken and allowed them to witness the abductor's getaway vehicle. The baby was recovered safely several days later. The moral hazard in this case: Given that hospital staff and new mother were aware of the RFID system's risk-reducing benefits, what new risks were they willing to take that they would not have otherwise taken? Did the reassurance of the RFID system make the mother more willing to allow her infant to be taken by an impostor with no hospital ID badge? Did the presence of the RFID system make the staff less willing to challenge the abductor, who was dressed in scrubs but lacked a badge? Did the technology in this case really contribute to the happy outcome, or did its moral hazard help the perpetrator commit the crime in the first place?

Healthcare IT project troubles have been documented at well-funded organizations like Cedars-Sinai, CHW, and Kaiser Permanente. The moral hazard of cash burning a hole in one's pocket is not unique to healthcare organizations. Having a lot of cash on hand -- a hedge against many forms of risk -- seems to encourage taking on overly-risky investments that can lead to high-profile project failures.

It is impossible to assert categorically that healthcare IT reduces the overall risk within a given institution. True, technology may provide a hedge against specific risks, but there will be a moral hazard in the way human beings respond to that reduced risk. And it is difficult to predict ex ante whether the moral hazard will outweigh the direct effect of the reduction in risk that is being sought in the first place.

Such was the case with the infant abduction cited above. The hospital's investment in RFID technology netted against the moral hazard created by the technology did not yield any benefit to the baby. In the end it was good old-fashioned police work -- not technology -- that tracked the infant down in Clovis, NM and led to her safe recovery. According to the article, hospital infant abduction is an exceedingly rare occurrance with fewer than 120 cases recorded in the past 20 years. It's something that security guru Bruce Schneier would call a "movie-plot threat", a threat with infinitesimal probability that causes panic nonetheless because it appeals strongly to our emotions. The threat of hospital infant abduction is apparently compelling enough for the 900+ hospitals that had bought the VeriChip RFID infant security system as of 2005. I wonder how many VeriChip customers have also purchased marmoset insurance.

Unfortunately, too many provider organizations treat healthcare IT as an insurance policy rather than an investment that is expected to add value to the organization. Too many healthcare IT vendors enable the problem by recognizing that it's easier and much more lucrative to sell on fear, uncertainty, and doubt (FUD) than to quantify and demonstrate a return. And ironically enough, moral hazard creates additional risk whenever providers and vendors try to mitigate risk with technology, resulting in a viscious cycle that consumes vast amounts of capital without providing any real benefit.

Wouldn't we all be better off treating healthcare IT projects as investments rather than insurance and focusing on the value they can create within the marketplace?

Kaiser HealthConnect: A Disaster of Epic Proportions?

zm — Wed, 08 Nov 2006 06:41:00 GMT

No doubt you've read the news: A 25-year-old Kaiser employee named Justen Deal has blown the whistle on the HMO's multi-billion-dollar implementation of HealthConnect, Kaiser's in-house name for the product suite provided by Epic Systems Corporation of Verona, WI. There's no need to rehash the story here, but I would be remiss if I did not take this opportunity to point out how these allegations relate to the economics of healthcare IT and software in general.

To sum up: The problem at Kaiser seems to be one of taking a system that had been quite successful on a smaller scale with fewer requirements and pushing it well beyond its limits. Kaiser CEO George Halvorson praised outgoing CIO J. Cliff Dodd -- the first but probably not the last executive casualty of these revelations -- for making HealthConnect "the largest civilian automated medical record system in the country." What he didn't say is that HealthConnect is at least one order of magnitude larger than the next-largest Epic implementation. How could it be otherwise considering that few organizations can rival Kaiser's size? There are only so many organizations that have 180,000+ employees to begin with, and only one of them is in the business of healthcare as far as I know.

Halvorson went on to say:

"We need our systems capability and infrastructure to perform at levels that will let us compete successfully with health care providers, health care systems and mega health plans that are investing heavily in their own systems capabilities."

This comment is a tacit admission that Kaiser will lose any competitive advantage it may currently enjoy if it cannot scale its systems to fit the size of its organization. Kaiser's competitors are moving ahead with their own systems capabilities, but Kaiser is hamstrung by the difficulty of scaling its systems to fit its enormous size. It's quite a bleak picture, but it gets worse when you consider the underlying economics of software integration on a such a large scale.

As I've discussed previously, the cost of developing software is an exponential function of the software's size. The intrinsic value of integrating software is a function that grows much more slowly than does the cost. The cost of developing a tightly-integrated software system is bound to eclipse its value at some point, and if any healthcare organization is approaching or has already reached that crossover, it's Kaiser. The fact that Deal reports Kaiser to be spending $1.5 billion per year on HealthConnect and other IT projects gives us an idea of just how badly the cost of their largest-integrated-system-in-the-country has scaled.

Smaller, more-specialized companies that compete with Kaiser therefore enjoy a competitive advantage because their software systems are more functional and more cost-effective. Since these other companies don't have to achieve the same level of integration across functions as Kaiser, they can enjoy greater functionality with fewer tradeoffs, thereby making them more competitive. What's more, the reduced size of these specialized software systems means Kaiser's competitors pay relatively fewer dollars per unit of functionality.

Assuming, as Halvorson says, that well-performing systems are essential to Kaiser's ability to compete, the fact that Kaiser's competitors are becoming absolutely more competitive by investing relatively less money means that eventually it will become impossible for Kaiser to compete no matter how much money it sinks into its systems.

Perhaps we've entered an age in which the size of any competitive business is limited by its ability to scale its software systems. Businesses whose size precludes them from acquiring or building well-performing software systems may find that the only way they can compete is to shrink or split into reasonably-specialized businesses that are small enough to slide back under the software cost-value crossover point.

Could a presently-unfolding failure of HealthConnect ultimately force Kaiser to split itself up into more-specialized entities in order to stay alive? Given what George Halvorson has said about the importance of the project and what we know about how software behaves as it becomes increasingly complex, it's reasonable to conclude that if an IT project failure can bring down a healthcare organization, then Kaiser, the largest and most complex of all such organizations, is certainly most at risk.

Response to RaleighHIS: Meditech "Integration Story"

zm — Fri, 03 Nov 2006 05:58:00 GMT

RaleighHIS asks:

"Re: Meditech. How does the integration story play so well? 30+ servers, databases that need to be 'synced'. Yet they tell the 'integration story' and people buy it!?"

There can be little doubt that Meditech is the most-successful healthcare IT vendor today, having recently posted quarterly net income that rivals that of Cerner on revenues of $87.4M to Cerner's $345.5M. Cerner may be the industry darling on Wall Street, but Meditech is laughing all the way to the bank.

RaleighHIS seems to infer that Meditech's "integration story" propels them to success. I disagree. Meditech's system seems to be no more or less "integrated" than those of the other major vendors, all of whom seem less than eager to admit that they have some fairly loose coupling within their allegedly highly-integrated architectures.

I think Meditech's currently-unmatched success is a product of their superior understanding of their business and their market. They seem to understand that it's not economically feasible for them to attempt to be all things to all people, and the resulting focus has a phenomenal impact on the bottom line.

A vendor who understands its business understands its cost structure and avoids making unprofitable commitments under the guise of growing the top line. Meditech frequently tells its clients and prospects "No, we're not going to do that." It may seem counterintuitive at first glance, but it is focus that enables excellence and profitability. Focus is by definition exclusive. You can't be exclusive without saying no, and you can't know when to say no unless you really understand your business.

What's more, in order to know when to say no with confidence, you have to know your market. And Meditech does, arguably better than any major vendor. They know that they don't have the best solutions in terms of functionality -- some of their code is probably 35 years old and they have resisted the urge to rewrite it every time a new technology-du-jour is announced -- but they can win on value (functionality/cost) every time because their product is rock-solid and offered at a price that no other HIS vendor can match.

So I think Meditech wins not on integration but on value, which is derived from a clear understanding of the market and their particular business.

Meditech's competitors, on the other hand, seem bent on integrating their way to market dominance. But as I've written before, companies in other industries have overestimated the value of integration, sometimes with dire consequences. Similarly, few software businesses seem to appreciate the exponentially-increasing cost of integration, which implies that there is an upper bound on the economic feasibility of any software system of increasingly complex integration.

A sufficiently-integrated, low-cost, rock-solid system like Meditech's has a distinct competitive advantage over that of any other vendor who hopes to integrate their way to differentiation by pouring an exponentially-increasing number of dollars into R&D. That's why Meditech wins today, and that's why no other vendor will be able to touch their financial performance in the forseeable future.

Commentary on HIStalk Jonathan Bush Interview

zm — Thu, 02 Nov 2006 12:37:00 GMT

This morning Mr. HIStalk ran a very good interview with Jonathan Bush, Chairman and CEO of athenahealth, who seems to be a visionary and articulate executive poised to do great things for the industry. I'll comment on one of his points in particular:

"Everyone needs to have a service with their EMR that drives integrity. Doctors will be paid for performance – why aren’t vendors willing to go at risk? That makes me a little pissy. We just got legal clearance to charge for athenaClinicals as a percentage of doctors' claims settled. We don’t charge for the encounter and there's no upfront fee or flat fee. Originally we had some Stark concerns, but now it's OK. The administration has done a great job of getting regulatory clutter out of the way for improvement. There is much more long-term benefit than putting a disconnected legacy EMR in every pot."

Kudos to Jonathan and his company for raising this issue in the arena of public debate. I couldn't agree more with his comment about at-risk payment for healthcare IT vendors. As higher-profile vendors begin offering this type of service contract to providers, the economics of the industry are bound to change for the better, but only if both providers and vendors decide to get on the bus.

I imagine that a "pay-for-performance" trend in EMRs has a better chance of beginning in the ambulatory rather than the acute-care segment. My conjecture is that there has to be some upside for the EMR vendor in an at-risk agreement -- a bonus if the vendor exceeds expectations -- and as risk-averse as hospitals are, they are likely to opt for a fixed payment even if it is higher than the expected value of the at-risk option. But physician practices are inherently more entrepreneurial, perhaps less risk-averse, and have simpler decision processes so they can make a decision to go at-risk without getting bogged down in a byzantine series of committee meetings.

My experience has been that the stakeholders involved in a decision to purchase a hospital EMR (or any hospital-based clinical information system) rarely if ever view the purchase as an investment that is expected to pay a return. As Jonathan seems to suggest, perhaps this is a matter of the way the industry-leading vendors position their systems, ignoring the ROI issue because they know they are asking a price that far exceeds the measurable value of their product. Still, one can't help but wonder about the soundness of hospital decision processes that consistently produce one eight-figure IT boondoggle after another, each allegedly following months of "due diligence" on the part of the stakeholders involved.

Another key challenge in an at-risk service agreement is choosing the metric that will measure the vendor's performance. Revenue seems to be the lowest common denominator, but the pathway from care to dollars is anything but clear, especially in an acute-care setting. Complexity affords opportunities for variance, and I can see how a provider organization could argue that any increase in revenue could be due to any of the multitude of other variables apart from the performance of the vendor's product or service. Jonathan mentioned that the government has taken important steps to reduce the "regulatory clutter", and I imagine that the more we can simplify the relationship between care and revenue, the more likely an at-risk pricing model will catch on across the entire market.

If Jonathan and athenahealth can begin to make a difference on how the industry views investment in clinical information systems, both the provider and vendor sides of the industry will be better off in the long run as the relationship between the cost and value of healthcare IT becomes more balanced.

Why Large Software Systems Fail

zm — Tue, 31 Oct 2006 08:00:00 GMT

In a previous article we took a critical look at Metcalfe's law, focusing on the recent and well-reasoned argument that otherwise-intelligent people frequently overestimate the intrinsic value of network effects. In this article we'll examine the second half of Metcalfe's law -- the cost curve -- to demonstrate that while there might be a "critical mass crossover" point in communication networks beyond which network effects begin to dominate and the network explodes as a success, software systems exhibit the exact opposite behavior: A crossover point beyond which a system rapidly collapses on itself, creating a black hole that sucks up every unfortunate dollar that floats within its Schwarzschild radius.

If you think the following topic is esoteric, hard to follow, or even scarily geeky, you may be right. But given the amount of money you may have riding on bets that any one software architecture can be all things to all people, you owe it to yourself to become somewhat familiar with the underlying principles that seem to govern how software behaves on a large scale. Best of all, this article will provide a foundation for a subsequent empirical analysis of the long-term viability of the software and vendors that currently power the healthcare IT industry. Read on, and I'll do my best to keep the topic understandable.

Our journey begins decades ago in the field of Electrical Engineering. Since most early computers were built and programmed by engineers, it's only natural that these early computer scientists put their computers and programs to work solving the problems that were most relevant to their own work. One such problem is known as the Boolean satisfiability problem (SAT).

The driving force behind SAT was to reduce the cost of building circuits by simplifying them. A logic circuit is designed to take some set of Boolean (0-1) inputs, apply some logical operators (AND, OR, NOT, etc.), and produce a Boolean output that tells you something useful about the inputs. That is, of course, assuming that the circuit is actually capable of telling you something useful in the first place. Such a useful circuit is called satisfiable, meaning that there is some combination of inputs that will produce an output of 1. A circuit that is not satisfiable will always produce an output of 0 regardless of the inputs, meaning that the entire circuit can be replaced by a 0, thereby saving the cost of building a circuit that does nothing.

An obvious way to solve SAT is by brute force: For a given circuit, test all possible combinations of inputs until you get an output of 1. Easy enough for circuits with 2 or 3 inputs, but consider that even a fairly trivial circuit with 10 inputs has 1024 unique combinations of those inputs and you begin to appreciate the scope of the problem. For a circuit with n inputs, you will need up to 2^n test cases. A circuit with 32 inputs could require more than 4 billion test cases to prove satisfiability. Ouch!

It's easy to see that SAT can quickly become quite a hard problem to solve as the number of inputs grows. As a matter of fact, SAT is so hard that it came to define what the term "hard problem" means. Computer scientists began to say that SAT is NP-complete, meaning that the problem can't be solved deterministically in a polynomial number of steps with respect to the number of inputs. In other words, the cost of solving SAT -- or any other NP-complete problem -- is at least an exponential function of the number of inputs.

But not all SAT instances are created equal. Some can be shown to be satisfiable very quickly, whereas others could take up to the theoretical maximum number of steps before we could prove or disprove satisfiability. In 1992, Mitchell et al. published a paper entitled "Hard and Easy Distributions of SAT Problems" that contained the results of an experiment that involved generating numerous random SAT problems of varying complexity and measuring the probability that a problem of a given complexity is satisfiable. The results were somewhat surprising.

Intuition would say that complexity and the probability of satisfiability are negatively correlated. That is, the more constraints you put on the inputs of a circuit, the greater the probability that they all confound each other and produce no meaningful result. Mitchell's research found that there is indeed negative correlation; but while one might imagine that the relationship between probability and complexity would be somewhat linear, it turns out to be much more interesting:

Mitchell's research showed that very simple SAT problems are always satisfiable, very complex problems are never satisfiable, and somewhere in between the very simple and very complex problems there exists a limit around which probability changes quickly and dramatically, and this is where the hard problems lie. The cost of determining satisfiability peaks roughly at the point where the probability equals 0.5, meaning that it is most expensive to solve problems whose chances of satisfiability (or not) are 50-50.

Geek trivia: Many researchers have worked to refine this experiment since Mitchell's original work, and interestingly enough the maximum cost and probability of 0.5 always seem to concur at the point where complexity (a ratio of the number of constraints per input) is about equal to 4.3, a number that is beginning to appear to be woven as tightly into the fabric of information science as is pi into that of geometry or e into that of exponential growth and decay.

Here's where things start to get fun: If you can prove that a particular problem can be reduced mathematically to SAT, then that problem is also NP-complete and behaves the same way SAT does in terms of both the probability that it is solvable and the cost of the solution as a function of complexity. It turns out that software design is reducible to SAT, which leads us to a fundamental law of software systems that helps us understand the economics of software production: The cost of producing software increases exponentially as we add constraints -- also known as features -- to a software system.

Remember that Metcalfe said the cost of creating a communication network would increase linearly and the value of the network would increase quadratically (polynomially) as functions of network size, leading to "network effects" once a "critical mass crossover" point is reached. Odlyzko et al. did a good job explaining that Metcalfe's value function isn't really quadratic, it's n log n; but that relationship still produces network effects, it just moves the crossover point significantly farther out from where some of the failed telecoms of the past decade bet that it would be.

In contrast to that of hardware networks, the cost of creating software increases exponentially as a function of size, and this behavior completely changes the economics of network effects for featurewise growth of a software system.

Notice that for both communication networks and software systems the cost and value curves cross over each other. In the case of communication networks, the value curve overtakes the cost curve at what Metcalfe appropriately called the "critical mass crossover" point, alluding of course to the amount of fissile material necessary to create a self-sustaining nuclear chain reaction. Large communication networks are therefore self-sustaining and feasible whereas small networks are bound to peter out if they fail to reach critical mass.

In the case of software systems, however, the opposite is true: The cost curve overtakes the value curve, meaning that small software systems are feasible and sufficiently-large ones are not. It's important to note that this cost-value crossover is an inevitability, the cost function is higher-order (exponential) than the value function (n log n, or at best polynomial of you don't believe Odlyzko), so cost will overtake value at some point as software complexity increases, it's just a question of where.

We can use the exponential software-development cost curve to describe three classes of software companies. I think this exercise will help you see that you can classify a software company's proximity to the critical-mass-crossover point based on some key characteristics of its business model:

1. Startup. The exponentially-increasing cost of software development starts out deceptively low, much lower than the value the software provides. Most software also starts out as a blank slate, its design largely unconstrained by previous decisions. Accordingly, in the startup phase software development is a relatively easy and very high-leverage activity. It's easy to make the software do exactly what you think the market wants because the code and the team are small, easy to manage, and quite unconstrained. Every dollar invested into development yields many more dollars of value for the company, meaning that in this phase a company experiences what economists call increasing returns to scale, commonly called "economies of scale". If a company doesn't survive this phase, it's demise usually has nothing to do with the economics of its software and more to do with poor product management, i.e. building the wrong product, competing in the wrong market, etc.

It should go without saying that since startup-phase software is the easiest software to get right, software startups and other companies still operating in the startup phase should account for the majority of software companies in business at any given time. Despite a lack of hard data to prove it, I'm highly confident that such is the case; even a quick tour of the exhibit floor at HIMSS always shows a disproportionate share of newcomers and other startups.

2. Slowdown. Success in the startup phase can give software entrepreneurs starry-eyed visions of world domination. I'm reminded of a Dilbert strip in which the Pointy-Haired Boss gleefully exclaims something to the effect of "The farther I scroll this spreadsheet to the right, the bigger the numbers get!" No doubt those in similarly exuberant states of mind are basing their forecasts on a linear software-cost curve, the assumption that a feature tomorrow will cost the same as did a feature yesterday or today, ad infinitum.

But we now know that the linear-cost assumption is flawed. It will cost the company more to add a feature to its product tomorrow precisely because it added features yesterday and today. The probability that those features together -- plus all those created heretofore -- will do something unexpected (bad) increases exponentially, as therefore does the cost of creating a design that actually works, to say nothing of verifying it later.

The result is that the cost of producing software increases as the company hits the "knee" of the exponential-cost curve, a region characterized by more or less constant returns to scale where the slope of the cost function is about the same as the slope of the value function. The economies of scale of the past are now gone, and the company may find itself in dire straits if it relied exclusively on that extreme leverage for its profitability during the startup phase.

Though I can't present supporting evidence at this time, my conjecture is that the vast majority of software companies that successfully leave the startup phase end up starving to death in the slowdown phase as the ballooning costs of software development overwhelm their profit margins. As they begin to falter, these companies may be picked off by bigger competitors or have their lunch eaten by a startup with a lower cost structure who can compete more effectively on price, and a lucky few may survive to the next phase.

3. Stagnation. Some companies may survive the slowdown phase, but if their strategy is to continue adding features in an attempt to dominate the market, their software is destined for stagnation.

An astute company that is measuring the profitability of its software-development projects will recognize when it is realizing decreasing returns to scale, or diseconomies of scale, on its continued investment in featurewise development of its software product. Diseconomies of scale in this phase may seem somewhat counterintuitive since we typically associate "economies of scale" with the larger companies who tend to be the ones that make it this far. But any economist will tell you that marginal cost (MC) curves always turn upward as quantity of production increases, and the more-astute software companies understand that they cannot be exempt from the increasing marginal cost of developing features, their primary units of production.

A software company may choose to implement one or more strategies to deal with the stagnation that comes as software development costs increase rapidly on a collision course with the value curve:

It may begin to invest more heavily in a related professional-services business, as such businesses typically enjoy margins that are relatively high when compared with those of stagnating software products. Service businesses also scale nicely as they are not bound by the nasty exponential cost curve of software development.
It may play "You-Bet-Your-Company" by raising large amounts of capital to redesign the software product from the ground up to remove unnecessary constraints. This game is a gamble that when the rewrite is over the company will enjoy a lower cost structure that will enable future growth, and that no essential feature (constraint) will be left behind in the meantime by mistake.
It may choose to grow its software-product portfolio by acquisition rather than by its own development efforts. Buying a smaller complementary product makes good economic sense because features can be added to the new smaller product at a lower marginal cost than that of adding the same features to the stagnant product. However, the company will have to provide some level of integration of the two product lines, and tight integration of a newly-acquired product can be just as expensive as building the product from scratch in the first place. More on this topic later.
It may stick its head into the sand and ignore the problem, especially when facing its customers and prospects. After all, it's likely that customers know very little about software development or the behavior of software in general despite their willingness to spend enormous amounts of money to acquire and maintain it.
It may foresee the inevitability of its software situation and shift its business strategy away from product excellence -- featurewise domination of every market niche -- and toward operational excellence by focusing its efforts on its most-valuable software assets and finding new ways to leverage those strengths into downmarket segments by simplifying its operations to lower its cost structure.

In spite of any company's best efforts to the contrary, it is extremely likely -- even certain -- that decreasing returns to scale will continue and even accelerate as the complexity of software increases and eventually reaches a point of instability, just as the formation of a black hole is unavoidable once enough matter is gathered into one place. Regardless of how highly structured the matter may be, once the mass fits within its Schwarzschild radius it will unavoidably collapse on itself and form a supermassive black hole. In sharp contrast to the "critical mass crossover" point of communication networks, that of software systems isn't one of self-sustaining success, rather one of the inevitable and total collapse of a product sufficiently bloated with features: The Schwarzschild radius of software systems.

Metcalfe's Law: Manifest Destiny of Cerner and Epic?

zm — Wed, 25 Oct 2006 13:00:00 GMT

In the previous article I promised to delve into the question of how the "big three" vendors and their peers can justify themselves as legitimate niche businesses within the broader IT and services market while simultaneously scorning their smaller rivals as "niche" healthcare IT vendors. To understand the answer, we need to turn back the clock more than 30 years to an early Silicon Valley success story that indirectly may have inspired the irrational exuberance of the Internet bubble and may -- according to at least one group of people much smarter than me -- be the driving force behind the recent Web 2.0 (or Bubble 2.0 as some cynics would say) phenomenon. Can we extend the same reasoning to the healthcare IT market? Read on and decide for yourself.

Back in 1973 an MIT and Harvard graduate named Bob Metcalfe was working at Xerox PARC and invented something he called Ethernet, which turns out to be one of the reasons why you are able to read this blog today. In 1979 Metcalfe left PARC and founded 3com, a company that made quite a bit of money over the years selling networking gear. Metcalfe's greatest claim to fame of late seems to be his eponymous Law: Simply put, that the value of a network is proportional to the square of the number of its nodes (n^2), which seems almost obvious if you know anything about discrete math and complexity theory.

As someone who planned to make a lot of money selling network gear, it's easy to understand why Metcalfe would have been excited by this principle. It meant that the value of the networks he was enabling his customers to create would grow at a rate that far outstripped their cost (he assumed cost was a linear function of n) once some "critical mass" was reached. Here is a reproduction of a 35mm slide that Metcalfe claims he used to illustrate the point in 1980:

In other words, building a large Ethernet would eventually be a no-brainer. And to his credit, Metcalfe's Law worked quite well for Bob Metcalfe and 3com.

Fast-forward 20 years to the Internet boom. Metcalfe had long since departed 3com, but Metcalfe's Law was still going strong in the business strategies of many of the high-flying telecom companies building the infrastructure of the promised New Economy, they having made enormous capital investments banking on "network effects" to eventually kick in and create value far in excess of cost. They were gambling on network traffic doubling every three to four months as it had in 1995 and 1996, but few industry observers noticed before it was too late that the actual growth rate had slowed to a fourth of that rate. We all know the rest of the story: These companies took on massive debt to finance growth that ultimately didn't materialize, the dot-com bust devastated the industry and was followed closely by a wave of accounting scandals that produced the largest corporate defaults in the history of the free market.

Andrew Odlyzko, formerly a researcher at AT&T Labs and now on faculty at the University of Minnesota, was one industry observer who foresaw the slowdown in growth that ultimately contributed to this calamity. In March 2005 he and Benjamin Tilly published a paper refuting Metcalfe's law as overestimating the true value of a network. They contend that the value of a network of n nodes, rather than being proportional to n^2, is instead proportional to n log n since the value of each network connection is not equal, and by Zipf's law the distribution of value by connection is a powerlaw. In layman's terms: The value of a network still grows faster than its cost, just not nearly as fast as Metcalfe had assumed; and the difference between the assumed rate and the actual rate may have been the undoing of many telecom and Internet companies.

In July 2006 Odlyzko, Tilly, and Bob Briscoe of BT published a follow-up article in IEEE Spectrum, bluntly titled "Metcalfe's Law is Wrong". Their thesis: The Web 2.0 phenomenon -- inspired by the success of Google, social networking sites like MySpace, and online video providers like YouTube -- is poised to repeat the Internet bubble of the 1990's based again on the flawed reasoning of Metcalfe's law. Metcalfe in turn recently posted a rebuttal on a partner's blog.

The ongoing debate over Metcalfe's Law may seem entirely academic, but the truth has profound implications for the healthcare IT industry.

We can certainly model a clinical or hospital information system as a network, whether it be a network of devices, departments, users, or even a hierarchical network of all these entities rolled up inside a larger network of hospitals and clinics. For the sake of this discussion, let's use the network-of-departments model since that is the most common battleground of the "big three" and their siblings vs. the "niche" best-of-breed vendors in the acute-care segment.

If Metcalfe is right, then the value of the system is proportional to the square of the number of departments using it. Double the number of departments on the system, and the value of the system doesn't just double, it quadruples. Of course, Metcalfe's Law assumes that the connections between each department have equal value. Therefore, connecting the ED to the Lab, Pharmacy, or (gasp) Patient Accounting is just as important as connecting the ED to Dietary or Rehab.

We could continue this thought experiment, but I'll spare you the agony. It should be clear to anyone who has worked on a hospital information system implementation that the equal-value assumption is absurd. We all know that Lab, Pharmacy, and Accounting are always in Phase One of the project, whereas Dietary and Rehab are relegated to the depths of the ill-defined scope and infrequently executed project plan of Phase Four. If connections to all departments were equally valuable, why would the same cast of characters get the short end of the stick in every implementation?

If Metcalfe's Law is sound and applies to healthcare IT, then network effects will eventually kick in and carry the "big three" to a position of market domination as they drive their smaller competitors out of every little niche. If Metcalfe's Law does not apply to healthcare IT or is fundamentally flawed, then so are the one-size-fits-all strategies of these current market leaders, as they and their clients will find that the "critical mass crossover" point of the cost and value curves fails to materialize after pouring hundreds of millions or even billions of dollars into their quest to find it.

Metcalfe's rebuttal to the recent IEEE article is an ominous sign for those healthcare IT vendors who have built their strategy on a bet that network effects will eventually emerge in their products. Metcalfe doesn't give any examples proving that his law is sound, rather he challenges his critics to find an example to prove otherwise, which is exactly what they did in their 2005 paper. Rather than explain why Zipf's law doesn't apply to networks as Odlyzko, et al propose, Metcalfe actually invokes The Long Tail in his defense, which concept is entirely based on Zipf's law in the first place. He goes on to concede that his "proportionality constant" in the value function may in fact be a function of n, but offers no reason why that function can't be log n. Metcalfe and his apologists (unaware as the latter may be) certainly owe us a better explanation of their zealous adherence to this dogma.

So why is it that big "niche" players like Cerner and Epic believe that their manifest destiny is to dominate every small niche in the healthcare IT market? You could blame the Kool-Aid, or you could blame Metcalfe's Law and its "network effects". But if the brilliant Bob Metcalfe who conceived this idea can't mount a more-convincing defense of his reasoning, does anyone imagine that Neal or Judy can do better?

The Long Tail of Healthcare IT

zm — Sat, 21 Oct 2006 21:47:00 GMT

If you have not already done so, you must pick up a copy of Chris Anderson's excellent new book, The Long Tail (or at least visit his blog). It will likely change the way you think about many markets, but I'll comment on how it applies specifically to healthcare IT.

The idea behind The Long Tail is that aggregate demand in a market of many different goods is a powerlaw distribution, as pictured above. For example: In a given market, for every unit of the most-popular good that consumers demand, they demand 1/2 units of the 2nd-most popular good, 1/3 units of the 3rd-most popular, and 1/n of the nth-most popular. Note that demand never reaches zero, which leads to the rather sensational conclusion that there is a market for everything, no matter how obscure.

Anderson uses real-world data to illustrate how this type of distribution applies to books, movies, television shows, and music, to name a few products in industries where such data are readily available. Powerlaws are not unique to marketing, nor are they by any means new. Anderson concedes that Pareto applied the idea to macroeconomics in the 19th century when observing the distribution of wealth in a population, and in the early 20th century Zipf found the same pattern in languages. Anderson certainly deserves credit for applying these principles to marketing in general and explaining in particular the rise of Long Tail business like Google (advertising), Amazon, Netflix, and iTunes.

A Long Tail certainly exists in the healthcare IT market. The "Short Head" of the market is easy to spot: Meditech, Cerner, Epic, McKesson, Siemens, and Eclipsys. These vendors produce the "hits", products that are the most universally appealing across the market. They account for the lion's share of the revenue generated in the industry and occupy a proportional amount of square footage on the exhibit floor at each HIMSS conference. Nevertheless, there are another 608 vendors registered for the 2007 conference exhibit, a Long Tail if ever there was one.

Mr. HIStalk, the venerable pioneer of the healthcare IT blogosphere, recently penned an article for Inside Healthcare Computing in which he argued that the "big three" of healthcare IT -- Meditech, Cerner, and Epic -- would achieve increasing dominance of the market because of the superior level of integration offered among their product lines. I'll argue the contrary based on a few key ideas from The Long Tail:

1. The enabling force of the Long Tail is the democratization of tools of production. Anderson explains that a world in which television, music, and movie studios were the only ones who had means to produce content was a world in which the hits were destined to reign, if for no other reason than a lack of choices beyond this mass-market fare. As advances in technology made the means of production more affordable, those markets began to become more highly differentiated, meaning that the "tails" of their demand curves began to lengthen as more diverse products were brought to market.

The sheer number of vendors exhibiting at this year's HIMSS conference makes it awfully hard to imagine that the democratization of the tools of producing healthcare IT products has not yet begun, and the fact that 80 or more of these vendors will be first-time attendees this year shows that innovation is alive and well on the periphery of the demand curve. Consider the acquisition of Azyxxi by Microsoft -- a business whose strategy has long been to provide "horizontal" tools for vertical markets rather than compete in those markets directly -- and you can imagine that the tools of producing healthcare IT products may yet become much more democratic in the very near future.

2. Given democratized production, the proliferation of products in the tail makes it difficult to distinguish those of high quality from those of marginal quality. A common misconception is that Long Tail products are all of poor quality, otherwise they would be hits. In fact, the quality of some products in the tail far exceeds that of those in the head.

Case in point: Go shopping for an audio system at Wal-Mart. You will find many different products from a few vendors, and the products will have a fairly narrow distribution in terms of quality. You won't find products that will go up in smoke as soon as you plug them in, but if you are a true audiophile, neither will you find any products of high enough quality to satisfy you. Like many other businesses that market the hits, Wal-Mart seeks to be an optimal tradeoff of convenience and consistent but mediocre quality to reach as large a market as possible. As much as their executives may disdain the label, at least two of Mr. HIStalk's "big three" are currently locked in a horse race to see who will become the Wal-Mart of the healthcare IT industry.

What if you're not satisfied with the choice of goods available at Wal-Mart? There's a brave new world out there in the Long Tail, and chances are that you'll find what you're looking for there if you have a good filter to help you know where to look.

The CCHIT certification that will be available for inpatient EHRs in May 2007 may prove to be just such a filter, a signaling device that a prospective buyer can use to filter out products that meet the commission's functionality standards. Rather than serve as a barrier of entry into the market -- perhaps as the market leaders would have hoped, a strategic lever to compensate for the force of democratized production described above -- the certification may in fact guide buyers to consider products that they would otherwise have not, and some of those lesser-known products (and vendors) will no doubt be of higher quality than the "hits" everyone is familiar with today. As has occurred in each of the industries profiled in The Long Tail, effective filters in the healthcare IT industry will drive more demand from the head into the tail, reducing the magnitude of the hits and "fattening" the tail as they match supply with demand more efficiently.

3. Finally, Anderson notes that powerlaws are fractals. That is, they have similar shape regardless of scale. Zoom in on a section of a powerlaw, and it looks like a powerlaw. Zoom out by orders of magnitude, and it still looks like a powerlaw. The implication is that a Long Tail is composed of infinitely many Long Tails added together, so no matter how many times a market is segmented, there will always be many, many niches to be exploited given democratized production and efficient filters.

After all, isn't healtchare IT just one small-but-fast-growing segment of the broader IT and services market? Don't IBM, Oracle, and Accenture consider Cerner to be a niche player? Can anyone honestly assert that the same economics that justify Meditech, Cerner, and Epic as viable niche businesses somehow don't apply to the 600+ companies currently thriving in just a few of the infinitely many niches that these "big three" and others have created?

The short answer to that last question is, of course, no; although many have tried and will continue to try to argue the contrary. The long answer unfortunately leads us down a rather fascinating but esoteric path not for the faint of heart, one that will have to wait for another day in the life of this busy blogger.