Month: December 2013

An article on Monday 16th December in the Oregon Business titled The promise and pitfalls of eHealth interviewed a staff member, Assoc Prof Aaron Cohen, from the the Oregon Health & Science University, which recently formed a partnership with Epic Systems Corporation — the first such affiliation by Epic with an academic institution.

A very interesting sidebar in the article is the description of a set of 9 unintended consequences of health IT. This is the list verbatim.

SIDEBAR: Nine unintended consequences of eHealth

Joan Ash, a medical informatics professor at Oregon Health & Science University, and her colleagues have identified nine types of harmful, unintended consequences that can arise when health systems implement computerized order entry. It’s an eye-opening catalog:

More/New Work Issues: Physicians find that CPOE adds to their workload by forcing them to enter required information, respond to alerts, deal with multiple passwords, and expend extra time.

Workflow Issues: Many unintended consequences result from mismatches between the clinical information system (CIS) and workflow and include workflow process issues, workflow and policy/procedure issues, workflow and human computer interaction issues, workflow and clinical personnel issues, and workflow and situation awareness issues.

Never Ending Demands: Because CPOE requires hardware technically advanced enough to support the clinical software, there is a continuous need for new hardware, more space in which to put this hardware, and more space on the screen to display information. In addition, maintenance of the knowledge base for decision support and training demands are ongoing.

Paper Persistence: It has long been hoped that CIS will reduce the amount of paper used to communicate and store information, but we found that this is not necessarily the case since it is useful as a temporary display interface.

Communication Issues: The CIS changes communication patterns among care providers and departments, creating an “illusion of communication,” meaning that people think that just because the information went into the computer the right person will see it and act on it appropriately.

Emotions: These systems cause intense emotions in users. Unfortunately, many of these emotions are negative and often result in reduced efficacy of system use, at least in the beginning.

New Kinds of Errors: CPOE tends to generate new kinds of errors such as juxtaposition errors, in which clinicians click on the adjacent patient name or medication from a list and inadvertently enter the wrong order.

Changes in the Power Structure: The presence of a system that enforces specific clinical practices through mandatory data entry fields changes the power structure of organizations. Often the power or autonomy of physicians is reduced, while the power of the nursing staff, information technology specialists, and administration is increased.

Overdependence on Technology: As hospitals become more dependent on these systems, system failures can wreak havoc when paper backup systems are not readily available.

Source: The Extent and Importance of Unintended Consequences Related to Computerized Provider Order Entry by Joan S. Ash, Dean F. Sittig, Eric G. Poon, Kenneth Guappone, Emily Campbell, and Richard H Dykstra; Journal of the American Medical Informatics Association (2007).

We would expect that our technology would mitigate most of these items. Emergent Clinical Information Systems (ECIS) technology along with Clinical Team-Led Design (CTLD) enables the clinical team to design their own system without the need for any intervening programming. The system designed will present full clinical workflows of all roles in the team, paper forms are reproduced electronically and fully integrated into the system, and there is no dependency on a superuser or IT staff.

This is crossposted with minor editing from my contribution to the AMIA Implementation Group list this morning.

We have recently completed a comparative study of two CIS/EMRs in an emergency department (ED) setting. In our discussion of the differences, we arrived at a number of theses and would be interested in your views about them.

1. Training time to learn how to use a CIS is a direct representation of its cognitive load. Our thinking here is: the more remote a CIS is from the workflow processes and content of the users’ known processes, the greater the amount of training and retraining time required for the user. A trauma doctor once said to us about a trauma CIS:

   If it takes more than 30 seconds to learn, then it is not good enough.

   Retraining time here is the extra training time you need after the initial training and also the assistance you need from the local expert user. Our idea is that systems that match the natural workflow of the user will be easier to use, and so have higher productivity.

2. Point-and-click interfaces break continuity of thinking and therefore cost time and make it harder to record the essential elements of the patient case. Many clinicians say it is easier to write on paper than do data entry into a CIS, and our hypothesis is that this is because point-and-click user interfaces break the continuity of thought that comes from a pen-and-paper strategy.

   It is our experience in designing many CISs that clinicians fall into one of two paradigms: holistic and atomic; that is, there are those who want to write the story, and there are those who want to atomise it into elements. We conjecture the first is a top-down approach and the second is a bottom-up approach, or alternatively, the aggregated approach and the disaggregated approach, respectively. These differences in thinking styles produce different views as to the desirability of different interface types: the latter comfortable with point-and-click interfaces; the former uncomfortable with them. We have worked with two different EDs who were at each end of this axis. Of course, practical systems are graded along this axis and no one solution is just one and not any of the other.

3. Cognitive load is also increased by unused components; that is, the extent to which components of a CIS are not of use to the clinician needlessly add to the cognitive load. Our notion here is that it is unhelpful to continue adding functions to a CIS if they are not going to be used, as it just makes the system harder to use, on average. Alternatively, providing a CIS that has a large variety of functions, many of which will be unused, will create a time cost and stress cost for staff which will reduce their productivity/efficiency. Hence, systems should be designed to supply “not-quite-enough” functionality, and then be “readily expandable” (this implies cheaply expandable) when the clinicians are confident they know what computerisation will be of the “next best benefit”.