William A. Hyman
Professor Emeritus, Biomedical Engineering
Texas A&M University, w-hyman@tamu.edu
Read other articles by this author
The recent ONC webinar on “EHR Usability & Health IT Safety” provided three interesting presentations on the design of EHRs and the influence of design on effective use. The slides and audio will be available here. The general issue here has been much discussed and relates to the often heard criticism, if not user outcry, that EHRs have not been adequately designed from the user’s perspectives, and that this makes them burdensome, and/or unhelpful, and/or actually dangerous. This situation continues even though the EHR Meaningful Use certification process includes the vendor submitting its “User Centered Design” (USD) methodology and testing to its certification body. Several items in the presentations caught my attention as follows.
With respect to the recurring complaint about EHRs not meeting workflow, a question was raised about whether or not new workflows could be designed into an EHR, perhaps even intentionally, that were actually better than the old workflows. That is, should EHRs facilitate workflow as we know it or should they build new workflows that are perhaps more efficient and perhaps even improve care. It was suggested that this is certainly theoretically possible. Even if this did occur there would be an interesting transition problem during which the EHR would be out of sync at first and then over some undefined period of time the work would evolve to meet the EHR and thus the work would then be improved. This might best occur if the better methods of the EHR were clearly articulated and the staff carefully trained rather than expecting some kind of unguided evolution. This would also require that justification for these better methods actually existed so that they could be articulated. To be avoided here is the vendor answering complaints by simply asserting that the users have been laggards in adopting the new and better processes.
The discussion of UCD process, testing and certification included interesting data on pre-release testing by actual “users”. Reports from 50 certified vendors were examined in order to identify the associated methodologies. Of these 34% did not report their methodologies, which is not a good start when such disclosure seems to be required. The remainder reported at least 6 different methods including 15% using ones developed in house. The number of test participants varied widely with 63% using less than the 15 testers recommended by NIST. In many cases none of the testers had a clinical background, and in 5% the only testers were vendor employees. It is fair to say here that certification has not created a high bar for UCD. An interesting suggestion was for customers to ask a potential vendor for their usability report as part of their selection process.
Some terminology that I liked, in part because it reminded me of some work of my own from two decades ago, was an attempted distinction between “user centered design” and “use centered design” (the first has the r on user in case you missed the difference).While perhaps a semantic game that only an academic could love, I think the point here is to bring focus on the end goal which is that the EHR is intended to be actually useful in its domain, and that such use is important. The user is important here of course, but the user experience is not the end goal. In fact in a different context it was seemingly suggested that an interface could be designed to intentionally slow down the user in the belief that slow is better for some cognitive tasks. This by the way is the origin of the QWERTY keyboard which was developed to slow typists down in the early days of mechanical typing. Who can remember untangling the arms when tangles did occur even with QWERTY? Who can even picture these arms, or has ever seen them? By the way my own work with “use” and “user” had to do with medical device errors where I argued that identifying a problem as a “user error” has already assigned blame while identifying it as a “use error” leaves open the possibility that the design of the device might have driven, or at least not mitigated, the error, ie the real problem might be usability.
There is much else of interest in the webinar, give it a look and listen.