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 Schleyer, DMD, PhD
Assoc. Professor and Director, Center for Dental Informatics