Bad Software

By James Kwak
Planet Money did a story this week on the problems with medical billing. This is something I’ve been vaguely interested in for a long time; nine years ago, we seriously thought about it as a business opportunity for our company.
The Planet Money team said that there is $7 billion in waste in the medical billing process per year, which sounds like a lot until you realize that it isn’t. (Total healthcare costs in the United States are on the order of $2 trillion, I believe.) But the story had a great example of the problems with enterprise software that I’ve written about before.
The story comes from Jonathan Bush, CEO of a medical billing outsourcer (they bill insurance companies on behalf of doctors and keep a percentage of the proceeds). It has to do with the codes that one of the Blue Cross/Blue Shield companies requires doctors to use to request reimbursement for a certain injection. The doctors used to submit eight-character codes for the procedure. However, the insurer decided that they wanted to negotiate lower prices for the drug itself from drug manufacturers. To do that, they need data on which manufacturer’s drug is used each time a doctor injects it–and that information isn’t contained in the eight-character code. So the insurer decided to switch to a different, eleven-character code for the procedure, since the longer code carries information about the drug manufacturer. (Note: this is what we want insurers to do, because it enables them to reduce costs.)
This is already a pain for doctors. But the kicker is that the insurer’s computer system only has space for eight characters for this particular code. So the insurer sent all of the doctors it works with a memo explaining how to compress the eleven-character code into an eight-character code.* This involved rules like “drop the first digit if it’s a zero, otherwise drop the sixth digit if it’s a zero . . .” that are not only a pain but that are sure to spawn enormous numbers of errors.
The underlying problem is a combination of: (a) the way data is stored in mainframe computers; (b) lack of foresight when designing software programs; and (c) difficulty in modifying said programs. (The better solution would have been for the insurer to write a program that did the eleven-to-eight compression automatically–but presumably it batch-loads the data it receives into its mainframe, and there is no staging area where it can do that kind of pre-processing. Or they were just lazy.)
Multiply this problem by a million and you have the state of enterprise software today.