Wednesday Aug 29, 2007

Helping to Eliminate Mistakes in Medical Treatment: What We Found (Part 3)

Loren Mack is a design architect in xDesign who creates strategic and tactical designs for the Service Oriented Architecture/Business Integration group at Sun.

This is the third entry in a multi-part series (View Part 1) | (View Part 2). In this part, Loren describes the findings of the user research that was conducted.

To solve the problems that we found, we followed classic user-centered design methodology: we didn't start with design. Instead we started by learning about our users. We visited several health care facilities that were already using the current version of the system, and we observed. We learned that health care professionals are very careful and methodical in their work. When they create a "match" between records, they’re certain it is, in fact, a match. They are serious (serious as my Granddad's gun-locker).

It turns out that most of the records that the system can’t match are easily matched by a human. Some common sense, some knowledge of the history of the hospital or facility where they work, experience with mistakes of the past — all of these things make it easier for humans, rather than for computer systems, to match certain types of duplicates.

For the handful of records that aren’t easily matched, quite a bit of legwork is required to figure out what should be done. Researching files, making telephone calls, talking to people in their facility, all of these tasks may be necessary to ultimately resolve a single case. Sometimes the resolution can take days, so our users may have a stack of "pending" matches on their desk that require their attention.

To further complicate matters, there’s an important standard with which all healthcare facilities must comply regarding confidentiality. You may have heard about this standard: HIPAA (Health Insurance Portability and Accountability Act of 1996). Most physicians require you to sign a paper stating you’ve read about and understand it before they’ll accept you as a patient. In the context of our project, we found out that each time someone looks at anyone’s medical information that "viewing" is recorded as a transaction to ensure complete confidentiality. So nobody’s flipping through medical files willy-nilly — they’re doing it because it's important (see previous "gun-locker" note).

After learning about our users, the problem was distilled into "How can we help them match multiple records quickly and easily, while allowing them some way of reversing a match if it turns out to be a mistake?" We started the process of brainstorming and kicking around design ideas. We mapped out the health care professionals' tasks and optimized the flows so that the most frequent and critical actions took the fewest number of steps.

This work resulted in a few key design requirements to make the complex matches easier to perform and track:

  • The ability to quickly see just enough information to determine if further research would be needed
  • The ability to see all the information across multiple systems (and to easily highlight the differences)
  • Having some way of putting a case in a "to be researched" or "pending" stack so that it could be retrieved quickly when new information became available
  • …and, of course…

  • Some easy way to reverse a match if it turns out to be an error

This kind of meaningful design work doesn’t happen that often, so when it does it’s really cool. Designing something that makes a difference to a lot of folks, not just the technical community — it's enough to make a guy proud. Sort of reminds me why I decided to do this kind of work in the first place.

Wednesday Aug 15, 2007

Helping to Eliminate Mistakes in Medical Treatment: Our Challenges (Part 2)

Loren Mack is a design architect in xDesign who creates strategic and tactical designs for the Service Oriented Architecture/Business Integration group at Sun.

This is the second of a multi-part series (View Part 1)

For this project, our design task involves finding a way to help health care professionals match records that the existing automated system can't.

The system is made up of two parts. The behind-the-scenes part consolidates a patient's records from various data sources to produce a single, complete, and up-to-date record of a particular patient. The system is even smart enough to see that records match even when some of the data in the records don't match.

The second part of the system is a user interface that reports records that might match, but that can’t be matched automatically. In this situation, the system needs some help from a "live operator standing by." Working with non-technical end users and providing them with awesome tools is one of the fun parts of this project.

When the system can’t resolve a conflict, the user interface alerts the health care professional and provides decision support to resolve the conflict. For example, when a baby is born, the hospital uses the father’s social security number as the baby's social security number on the birth certificate. Once common, this practice is now quite a headache for health care professionals later on, because the father and baby appear to be the same person. It's also a hard problem for the system to fix since the records of the father and baby may share the same data in many fields (like social security number and address), but the data in key fields are different (like name and birth date).

While there’s already a tool that lets a live human review these potential matches, it has many usability problems. It’s hard to tell what portions of a record don’t match. It’s hard to see information across more than one duplicate record (such as three systems all having similar, but slightly different data that could all be part of one person’s medical history). And it’s just plain slow.

These issues make it much harder for people to quickly and effectively handle records that the system can’t, and, in many cases, it takes much longer than necessary. Today, the people who do this work full-time print out huge lists of duplicate records and then spend hours reviewing the hard copies to make sure they’re matching the right information. The existing user interface could resolve these issues, but it doesn’t support their tasks well enough to be useful.

To be continued...

About

xDesign is a software user experience design group at Sun.
Follow us on Twitter : Flickr : Blog (see feeds below)

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today