EHR Vendors Have a Thing or Two to Learn from Apple

By the time you read this, Apple will have released its next round of new products. Millions will have undoubtedly been ordered. Problems are going to arise: some in design, some in execution. If you've just plunked down $600 to $800 for a new iPhone or Apple Watch and get a dud, or have a problem, I doubt that you're going to shrug your shoulders and say "Well, you can't win them all. Maybe I'll have better luck the next time." You are going to get your appointment at the Apple Store Genius Bar ASAP so you can get the problem fixed or get a new device.

The good news is that Apple expects this scenario and has prepared for it, and not only by having a Genius Bar and keeping their stores stocked with replacements. Bloomberg Businessweek reports:

"Within hours of a new phone’s release, couriers start bringing defective returns from Apple’s retail stores to the company’s headquarters ...  In a testing room, the same engineers who built the iPhone try to figure out the problem ... They take them apart to diagnose what’s happening right then and there.

"The program, created in the late 1990s, is called early field failure analysis ... The idea is to keep easily resolved problems from becoming punch lines for late-night comics. Often, they jury-rig a hardware fix ... Sometimes the problems can’t be solved quickly ... [but] every day they don’t recognize a problem, they are potentially manufacturing more bad products.... When you mess it up, you pay an enormous price.”

When you have a problem with your EHR or uncover a defect in its design or execution, what happens next? Does the vendor even become aware of your problem? If you're in an organization with an IT department, you probably have no direct line to the vendor. You first have to convince someone in IT that there is a problem - someone who is not a clinician and has probably never tried to use the product while delivering care.

The most common response from IT is "You're not using it right" when, of course, the flaw is precisely that, given the way it's been built, it can't "be used right."

Assuming that you've convinced IT that there is a problem, or if your practice is the customer, the next step is to call the vendor. The most common responses from vendors to this kind of call are:

1. No one has ever reported this problem before.

2. You're not using it right.

3. I hear you, but that would require a programming change. Changes like this are selected at the annual user's group meeting after everyone's requests have been noted, discussed, and prioritized. Then they are put in the development queue.

4. That would require custom programming which we could do for $XX/hour. If you agree (to the open-ended cost estimate) we will put your change request in the queue and get to it when it reaches the top of the pile. You may have to wait a year.

5. That would require custom programming and we don't do that for individual customers. [Go back to #3]

After getting any of these responses, who will ever bother to call about the next problem or defect (bug) they encounter? This leaves both the IT department and the vendor blissfully ignorant of how bad the EHR really is. From their perspective, the majority of their "installs" are a success. After all, no one has reported any problems.

What if physicians took this approach and didn't take much history or perform screening tests for cervical cancer, colon cancer, hypertension, diabetes, etc., unless the patient requested? After all, most patients will claim that they are "fine" - until the moment a catastrophe occurs. Apple, like a good physician, seeks out problems by taking every trouble call and every malfunctioning device seriously and treating each as a potential sign of a hidden flaw that needs correcting.

On the other hand, EHR vendors, like their products, are operating in the "dark ages," taking an approach to defects that is similar to the one that taken by Detroit in the mid-50s (and maybe still): Allow products with multiple defects to come off the line, fix the most obvious defects, one at a time, and wait for customers to complain about the others or until a defect kills a bunch of people.

For the technically minded: One reason to avoid learning about problems is that the architecture of your product, and the techniques used to build it, make it extremely difficult to change. It's simply too uncomfortable to keep hearing complaints that have root causes that you don't understand or can't do anything about. The natural response is to limit the inflow of bad news in every way possible. Your IT department and administrators have the same reaction. They can't do anything to fix vendor-caused problems and therefore would prefer that, if you have a problem, you just "suck it up" and not bother them with it.

Laissez les bons temps (et les défauts) rouler!