A big thanks to L-J Cunningham (@UXforHealth) for tweeting out this really cool time lapse video that shows SoftServe‘s work doing the UX design for the mEMR application. While the process they use is really cool to watch, it’s also interesting to see what a mobile EHR UI could look like.
A couple of weeks ago, someone posted an interesting question on the buzzing question and answer site Quora.com: Is there room for any more new EMRs in the insanely crowded marketplace we have today? According to one very sharp medical student who’s keeping an eye on the field, the best response isn’t “yes,” or “no,” but “you’ve got the wrong question.”
His answer, which I’d like to share with you, argues that there’s no point whatsoever trying to introduce a new EMR with a shiny new feature set when none of the existing field have a decent UI/UX right now. Jae Won Joh then lays out the steps he believes vendors should take if they want to get the basic UI/UX right (steps excerpted for brevity):
Step 0: Architect the patient data structure carefully
I mention this because you’re going to need to be able to pass this patient data around for clinical use, billing, research, auditing, etc, so design for flexibility and expandability from the get-go. Too many EMRs make it painfully obvious that things were thrown in as afterthoughts.
Step 1: Decide on your market…
…because you need to do everything possible to totally kill it. It’s the only way to go. If you’re going to take on group practices, great, take on group practices. If you’re going to work the hospital scene, fine, work the hospital scene. Stop trying to make something that does everything everywhere. This is not a feature, it’s a horrible bug.
Step 2: Analyze what your market does
If it’s a hospital, you need multiple classes of user, ranging all the way from student to nurse to physician to administrator. You’ll also want a competent notification system, because inpatient things tend to be more urgent and if the ICU patient’s potassium is critically high, you probably want to warn the physician immediately instead of waiting for the physician to check on it manually, because gee, the patient might code and die before that happens….The concerns are different for an outpatient scenario: you don’t need a lot of the stuff that hospitals require in an office. Less orders, more scripts, greater throughput in terms of number of patients, scheduling functionality, etc.
Step 3a: Abstract workflows to a very high level first
In other words, they are as follows:
1) read data
2) interpret data
3) input data
There’s really not much else to it. Every workflow is a permutation of those three. For example: a physician orders a lab, and it’s performed. The result is read by the tech who provides the input to the system, where it is then read and interpreted by the physician so they can go from there. Figure out how each workflow revolves around these three abstractions.
Step 3c: Design for a 5-year-old
If a five-year old couldn’t use your UI, you screwed up. Period.
There’s a lot more to Joh’s answer, and I suggest you hit Quora youself and read his entire piece. When it comes to usability, most EMRs have barely scratched the surface, and talking about these issues more is always a Good Thing.
Most of the critiques I read of EMR design ding the EMR for its difficulty to use or its inability to accomodate the workflow of the institution that bought it — and of course, sometimes both. What I’ve never heard suggested, however, is the following idea proposed by Chuck Webster, a guy who clearly doesn’t stop short when he decides to study something. (He’s an MD, an MSIE and an MSIS in intelligent systems design, which is only one of the reasons I think he’s onto something here.)
In a thoughtful and nuanced blog entry, Dr. Webster outlines the work of a pioneer in usability design, Donald Norman, and comes away with the conclusion that the current trend toward “human-centered design” might actually be a mistake. What a pain — health IT limps along catching up with a trend from the 1980s, and now may be too late to catch the bus.
In any event, Dr. Webster argues instead of focusing on human/user-centered design, EMR vendors should be focused on activity- or process-centered design. I love what he says about one of the potential problems with human-centered UIs:
Optimization around a user, or user screen, risks the ultimate systems engineering sin: suboptimization. Individual EHR user screens are routinely optimized at the expense of total EHR system workflow usability…I’ve seen EHR screens, which, considered individually, are jewel-like in appearance and cognitive science-savvy in design philosophy, but which do not work together well.
It’s better, he suggests, to have EMRs model “interleaved and interacting sequences of task accomplishment” first and foremost. For example, he writes, key task collections that should be considered as a whole include workflow management systems, business process management, case management and process-aware information systems.
While there’s much more to say here, of course, I’ll close with Dr. Webster’s words, who once makes his point with wonderful clarity:
User-centered EHR design does help get to good EHRs. Good isn’t good enough. If EHRs and HIT are going to help transform healthcare they need to be better than world-class (compared to what?). They need to be stellar. Traditional user-centered design isn’t going to get us there.
The question I’m left with, readers, is whether you can have your cake and eat it too. Does one side of UI/UX design literally have to be jettisoned to support the other?