I was privileged to attend the Informatics Institute at the ASHP Summer Meeting in Las Vegas. Let me first assert that, as an experienced informaticist, this programming was some of the most advanced, and most useful that I have experienced. Please join me in congratulating ASHP and the Section on Pharmacy Informatics and Technology for an excellent series of sessions.
There was a session early Sunday morning that caught my attention, delivered by two scientists from the Office of the National Coordinator for Health IT (ONC) regarding human factors.
The presenters identified that Human Factors issues fall into two "bins":
1) User interface issues
2) Understanding of the cognitive tasks that need to be performed by all the affected parties.
We are accustomed to thinking about the first bin. However, much of what has been known to occupy our attention on user interface design was fundamentally dismissed by the speakers as of secondary importance. Of most significance were:
Maintaining context - when scrolling or paging causes important contextual information (like who is the current patient, or what task am I doing, or what is the current date/time) to be lost, errors tend to increase. This is especially important when the user is switching context to do what they think of as multi-tasking. Indeed, the science the speakers presented showed that humans do not multi-task, they task shift. And this task shifting is associated with an increased tendency to err, especially when the user shifts back to the original task, and even more so when the user cannot easily detect that they are (or are not) in the correct context.
Minimizing cognitive load - this is related to loss of context. The more the user has to remember and bring forward information from a previous screen, the more likely they are to err.
Forgiveness and Feedback - the user interface must provide feedback in terms of the current progress of a task, and the choices the user has made, and then must be forgiving, in that it must be easy for the user to see the sum of what they have done, and repair whatever errors they detect in this process.
Naturalness - the user interface must conform to the user's expectations about the flow of the process.
The really important thing that came out in these discussions was about how user interface design could cause or prevent data-entry error. The above points were key issues that would either increase, or markedly decrease the likelihood of user error.
The second "bin" was far more interesting to me, which was the recognition and proper assessment of all of the cognitive tasks users must perform, and the ways they currently perform them.
Without going into immense detail (you should go review the slides on the Summer Meeting website), a significant point of failure in the design of healthcare computer systems is the appreciation of all of the users of a given system that is to be automated, and the cognitive tasks they need to perform. The use case was a white board in an emergency room that drove housekeeping, ER technician, ER physician and nursing behaviors with an extremely terse set of semaphores that drove behavior like when a cubicle needed to be cleaned and restocked, what attending physician activity was pending, when a patient could be discharged, etc.
The short story was that a large-screen display that focused on only one of the cognitive tasks involved with the white board went substantially unused while the white board was available, and once the white board was removed, the ER experienced a number of systemic failures because those cognitive tasks could no longer be performed.
A use case they presented that was closer to home involved an inappropriate administration of a fentanyl dose from a unit-based cabinet (UBC) because of the way items were described on the selection display of the unit-based cabinet. The key here was understanding not only what cognitive tasks needed to be performed but also the way in which the providers perform them.
In the use case, a patient was significantly overdosed with fentanyl because the physician ordered fentanyl 20 mcg, and the nurse's choices from the UBC were a fentanyl 50 mcg ampule or a fentanyl 20 mcg/mL, 100 mL infusion. You guessed it... the nurse saw the 20 mcg in the description of the infusion and delivered a 100 fold overdose.
Now, before we jump on the nurse, let us recognize the cognitive differences between a pharmacist and a nurse. Pharmacists are information junkies; we think that more information is better. Nurses are not, and do not.
The presenters argued that a different presentation of the item selection information on the UBC would have gone a long way toward presenting the errors. The important point is that the design should not be driven by what we think is useful and important, but by what the actual user finds useful and important, and safe. If the actual user is a not a pharmacist, then our preferences should be secondary to those of the actual user.
Note that the problem did not represent a defect in the functioning of the cabinet; it represented a failure to appreciate what the FDA sometimes call "forseeable misuse" by the people constructing the selection list (very likely the pharmacy).
I have only scratched the surface on what was an incredibly useful talk. But I hope it causes you to re-evaluate how you think about software design and usability.
As always... what do you think?
Dennis A. Tribble, Pharm. D., FASHP
Daytona Beach, FL
DATdoc@aol.com
#MedicationSafety #Technology #Informatics