Reduce Surprises Later By Trying Your EHR Before You Buy

From time to time I have described how difficult it is to imagine what requirements should be spelled out, and in what way, so that when you actually begin to use your new EHR it will behave as you expected. This turns out to be incredibly difficult because it is virtually impossible to guess how a developer might have chosen to implement a particular function or feature; typically you won't know what they did until you try it. Words fail to describe the subtle ways in which complex mechanisms behave, be they hardware or software. Complicating matters, words mean different things to different people. Written specifications that express sufficient detail to absolutely ensure that a product will look and behave as intended are possible, but are enormously expensive. These are required and cost-justified when building things like the Boeing 787 or the Airbus A380 - required because the planes are hardware and safety is critical. If the mounting holes in an engine are put in the wrong place, it's difficult to go back later and make an adjustment, cost-justified because the costs are small compared to the price of the plane and they minimize the chance that costly mistakes will be made.

Perhaps the most significant reason that precise specifications can be produced for a plane is that every aspect of the design is modeled, prototyped, and/or simulated before the specifications are finalized. The airframe is run through the wind tunnel. The flight simulator is built and pilots “fly” the plane before it is ever manufactured. Any control that is out of place or sub-optimal can be redesigned. Portions of the structure that will be subject to mechanical stress are mocked up and exposed to flexing, vibration, corrosive environments, hot, cold, etc., to validate the design and detect weaknesses prior to finalizing the manufacturing process.

Airplanes are not EHRs. The future demands that will be placed on an airplane are predictable and do not vary as greatly as the future unpredictable demands that will be put on EHR. Except for safety-related modifications, planes primarily need meticulous maintenance. It is a rare EHR (I can only think of one) where the core charting functions were engineered, prototyped, and test “flown” before the final product was built. Most EHRs have simply started with some feature that was considered to be pivotal and then have simply grown like Topsy ever since. As you recall, to grow like Topsy is to grow “wild, with neither plan, structure, nor direction.” EHR developers don't prototype, simulate, or test fly for many reasons but cost and the urgency to get the product to market come to mind.

Failure to validate the design and assess the potential reactions of users before finalizing the specifications can markedly reduce, but never eliminate, the mismatch between the product's properties and the user's expectations.

The impact of all this is captured by an experience that I have almost routinely experienced and which you may have also experienced. I start to use a new piece of software and within the first few minutes I encounter something that makes me exclaim “Why did they do THAT?” or “OK, I see how this works, now how do I (fill in the blank)? I encountered some examples of this after five minutes of starting to use the iOS 5 update on the iPad. There is a new “reader” function in the web browser and it offers two font sizes - so “How do I set it to default to the larger size?” Answer: You can't. There is a new reminder/to do list - so “How do I sort the items in the list in descending chronological order?” Again: You can't. You get the idea. I'm sure Apple worked on this new stuff for a long time and yet, I immediately discovered two “requirements” that are important to me that they either did not think of or choose to implement.

A final example. There is a web-based EHR product called Practice Fusion that I thought that I might be able to use in my clinic so I set up to give it a try. In order to use it I would have to print out the notes and have them scanned into the institution's imaging system. The notes would, therefore, have to conform to the institutional standards for where the patient identification information was placed on the page, how the pages were titled, etc. It became rapidly apparent that, although Practice Fusion has some attractive features, it does not include a feature to customize printed output nor does the vendor have any interest in implementing that function. For me, printing was a “drop dead” requirement so - no Practice Fusion for me. It's notable that it took less than 15 minutes to discover this roadblock.

A comprehensive EHR has many more modules, functions and features than an iPad. The number of things that you perceive to be missing or poorly implemented will surprise you as will be the rapidity with which you discover them. Then it's mostly a manner of learning to cope. It seems that the best, and perhaps the only, way to minimize the number of negative surprises you get after starting to use a new EHR, is to conduct extensive test flights before making a purchase decision. In the case of the iPad, the only chance for a test flight is after the “purchase.” In the case of Practice Fusion, it's web-based and free so test flights were feasible and I was rewarded by not making a major investment of time and effort only to discover too late that the product was not right for me. So you see, sometimes it is the little things that turn out to be of overriding importance.

Find out more about Daniel Essin and our other Practice Notes bloggers.