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
- Some easy way to reverse a match if it turns out to be an error
…and, of course…
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.
This is the second of a multi-part series (
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).
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.