How do we effectively get innovations in human-computer interaction into real-world software applications?

The other day, I got a Tweet from Ben Shneiderman at the University of Maryland about a human-computer interaction (HCI) innovation called Manylists. Ben is one of the world’s topmost HCI experts and one of my favorite Twitter leaders. Ben has an extremely high signal-to-noise ratio in his tweets, and if there was only one person I could follow on Twitter, he would be one of my top choices.

ManyLists is a product comparison tool that compares product features using spatial layouts with animated transitions. In simple terms, ManyLists arranges product features in a table in such a way that makes it easier to compare multiple products. The layout facilitates rapid scanning by the user, something I think we would all appreciate when buying a washing machine, a digital camera or junk food.

ManyLists looked similar to another tool developed in Ben’s lab, a medication reconciliation tool called Twinlist that I saw at a conference last year. Twinlist facilitates easy comparison/merging of a patient’s medication lists. For instance, a patient may be discharged from a hospital stay with a list of medications that may not be the same as she usually takes. Medication reconciliation, as it is typically done, is a relatively error-prone and effortful process. Twinlist does not fully automate the task, but provides clear advantages in helping the healthcare provider decide which medications to keep and which ones to drop.

Right after I got Ben’s tweet, I talked with Catherine Plaisant, an Associate Research Scientist who leads these projects. I was interested in the answers to two questions. The first one was what kind of HCI innovations Twinlist and ManyLists represented. Were they real breakthroughs or just incremental improvements? Catherine’s answer indicated that she thought they were somewhere in between. She pointed out that the applications really integrated several aspects of HCI done well: good graphic design, good choice of fonts and colors, and helpful animations to make  computational processes and their decomposition explicit.

The second question was more difficult to answer: How was she going to get these innovations into real-world software applications in an efficient and effective way? All over the world, programmers are busy creating medication reconciliation software. If they knew about her work, they could maybe improve on what she had done, instead of reinventing the wheel. Catherine did not have a good answer for that. Yes, the code and designs are openly available on request (just email plaisant at cs.umd.edu). But, it is an unsolved mystery for how to get these innovations into the hands of developers better than we are able to today (which is to say, not very well).

A few years ago, I came across the Common User Interface, a project by Microsoft in Great Britain, that offers a fairly large set of well-designed and tested user interface components for electronic patient records. I have always dreamed of plugging a new patient record together from these components. That would be certainly less work than writing it from scratch!

Best

Titus

– Titus Schleyer, DMD, PhD

Assoc. Professor and Director, Center for Dental Informatics

http://www.dentalinformatics.com/members/Titus+Schleyer

How can we improve the design of Electronic Dental Records (EDR)?

Those of us who develop systems for dental clinicians to use during patient care face a perennial quandary: How can we design systems that work like the intended users need (and want) them to? The way people usually try to answer this question goes something like this:

Programmer to dentist: “Tell me what the software should do.”

Dentist to programmer: “Well, I need it to do A, B and C. Also, we need to keep a record of D, E and F. … Tell you what. Here is a copy of the paper record we use – just make it do something like that.”

[3 weeks, months or years later] Programmer to dentist: “Here is the software I wrote for you.”

Dentist plays around with it for a while, then says: “That’s not what I needed …”

(A cartoon illustrating this phenomenon is here.)

Dissatisfaction among dental professionals with their electronic dental record (EDR) systems shows that there is a lot of work to do to close the gap between EDRs and the requirements of practice. One of my colleagues, Dr. Thankam Thyvalikakath, recently completed her PhD thesis titled “Designing clinical data presentation using cognitive task analysis methods” which has the potential to help narrow this gap.

I would like to talk a little bit about the basic informatics research that Thankam completed so ably. In order to find out how dentists review patient cases and make decisions, she conducted a relatively simple experiment. She asked 10 clinical practitioners individually to work through a set of three patient cases of low, medium and high complexity. The cases were comprehensively documented and presented in a standardized fashion. The experiments were audio- and video-recorded, and coded and analyzed. We then developed an EDR prototype, the DMDProject, to address some of the cognitive requirements which we elicited.

Here is an example:

As the figure shows, the ten study participants reviewed a patient case first by focusing on general patient information, medical history and the social history. They then proceeded to intraoral images and radiographs, followed by hard and soft tissue charts. Towards the end, they reviewed patient notes and refocused their attention on medical issues. The patient case was fairly complex, which was reflected in the participants’ intensive engagement with the patient record.

One of the key results of our analysis was that dental clinicians wanted an “overview” of patients whose record they reviewed for the first time. Strangely enough, very few EDRs offer this feature, which is relatively easily implemented using computer-based records but not paper-based ones. The resulting preliminary design implemented in the DMDProject looks like this:

In this design, the EDR shows a summary of the most relevant facts about Sarah Williams. It integrates demographic, insurance and clinical information. The last progress note is shown, as are scheduled procedures. The clinician also has easy access to the most recent images. (In the design, users can easily “drill down” to more detailed information from the Patient Overview.)

When we tested this design with users in several rounds of experiments, it was clear that it was a winner. Pretty much all clinicians commented very favorably on the usefulness of this view. So, we are hoping that more and more EDR vendors and developers adopt this design paradigm.

Thankam’s PhD thesis contains scores of other examples of how we elicited cognitive requirements of clinicians and then translated them into an appropriate design. Because it is somewhat hard to summarize a PhD thesis in a blog entry, I will come back to Thankam’s work in the future. (Sometime later this year, Thankam’s thesis will be available in Pitt’s D-Scholarship repository.)

All the best!

Titus

Titus Schleyer, DMD, PhD
Assoc. Professor and Director, Center for Dental Informatics
http://www.dentalinformatics.com/members/Titus+Schleyer