Optimized for Who?

I was reading this article on the data that patients need over at e-patient.net this morning.  Included was information on medications (or other treatments) that didn't work.

I let my mind wander (it does that on it's own if I'm not careful), and it roamed back to my days as a service department manager.  When a computer was brought in for service, we'd ask customers about the problem, and what they attempted to do to fix it.  Failed attempts were often even more informative (and time saving) than the symptoms.  The more symptoms you had, the more diagnostic pathways it opened up.  Rarely did a confluence of symptoms point to a single cause, because of the interconnected nature of the various components.  But a failed attempt to solve the problem could rule out a whole subsystem.

The franchise I worked for (ComputerLand) and various manufacturers would supply us with diagnostic maps providing diagnostic and repair procedures to resolve various problems.  Initially, my technicians would follow these procedures by the letter.  Over time though, we often found "shortcuts".  As computer service technicians, my team was measured primarily by how many computers, printers and monitors they fixed (but I also monitored revenue and margin).  So, they would optimize the procedures to allow them to complete more repairs.

You can optimize a diagnostic map and repair procedure by several measures: time spent, cost of repair, or revenue generated, and customer satisfaction.  For example, the simplest and fastest way to resolve just about any problem with a hard drive was to replace it.  But that is also the most expensive solution, and the least satisfactory to the customer.  The warranty repair procedures provided by manufacturers were clearly optimized to reduce their part costs.  They'd take a cheaper, but less likely to resolve the problem path first.  They'd rather replace a drive cable or cheap IDE controller, than the more expensive drive.

General repair procedures, even though it wasn't obvious, were optimized to increase profit.  They'd replace an expensive part when a simpler repair could have been used.  But they were also optimized to deal to ensure repair and reduce technician time.  That was probably a much more complicated optimization problem.  My tech's short-cuts invariably re-optimized procedures to reduce their time, and then, I'd have to remind them that time was not our only interest, so was income and customer satisfaction.

One particular problem I recall was for a squeaky hard drive.  Back in the days of the full size (5¼"x8"x3½") drives, many high-quality/high-capacity drives had a static discharge tab containing a graphite contact that touched the drive spindle at the base of the drive.  The purpose of this tab was to ensure that any static build-up was discharged to ground rather than affecting the drive electronics.  Over time, the graphite contact would wear away, and when the spindle hit metal instead of graphite, the drive would emit a truly annoying squeal.

There were three solutions to this problem.  The "overkill" solution was to replace the hard drive.  We agreed we would offer this solution last.  Most often, customers taking this solution were looking for a bigger/smaller/faster drive anyway.  The "recommended" solution was to remove and replace the graphite tab.  This was about a half-hour bench job, and would cost about $65 (fifteen  years ago), plus parts ($5 for the tab, for which our markup was %1000).  This left the drive at "spec" and solved the problem.  We didn't always keep these parts on hand, because they were infrequently needed, and easily obtained (1-day turn-around at a local electronics supply warehouse).  But sometimes they were out too, and it could take a week if ordered from somewhere else.

The simplest option took five minutes, and involved removing the tab with a pair of scissors.  The tab itself wasn't necessary to the functioning of the hard drive.  It served a protective purpose that wasn't truly necessary most of the time (kind of like an appendix).  I never heard of a drive where we removed this tab failing because of the removal.  This was a five minute bench job (for which $35 was my minimum charge).

We'd offer our customers these choices in cost order from lowest to highest, and recommend the middle solution (replace the graphite contact) as the "best" choice.  My "higher-end", more knowledgeable customers  would take the first choice (cut it off), and the next time they had the problem, would do it themselves.  My mid-range customers would take option 2 or 3 (depending on whether they wanted a new hard drive or not).  Option 1 became more favorable when we didn't have the parts on hand, and our supplier was out too.

Making these choices clear to the customer was really the key to optimizing for customer satisfaction.

Back then, the machine learning algorithms for optimizing decision trees like those in diagnostic maps weren't part of the basic curriculum.  These days, they most certainly are.  It would be interesting to see how different healthcare treatment choices optimize from the patient, provider and payer perspectives.

I recall my wife's knee surgery.  She had been recommended Physical Therapy first and she took that option.  After three years, she finally got fed up and had the surgery, which worked great for her.  My insurer paid more for the three years of off-and-on PT than they did for the knee surgery.  

They were optimizing for a short-term horizon, and they lost out.  That particular problem represents a prisoner's dilemma.  If all payers provided the most cost effective treatment for patients, everyone wins.  But if one payer defects (taking the short-term win), others lose.  The challenge here is that we all wind up losing.  Eventually, everyone defects, and all lose.  We wind up paying more, because the cheaper treatment gets the patient off the rolls, rather than healed.

I realize that not all cases are as treatable with surgery a my wife's was. That situation simply provides an example that I imagine occurs enough times that it's worth looking at in more detail.