Jon Patrick

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”.

Health IT can be a very effective tool for patient care, but can also be harmful and dangerous when improperly implemented. We will not rate this by medical criteria, but by operational criteria, we would say that the top five HIT dangers, in no particular order, are:

1. Records lost due to programming faults – programming errors
2. Incorrect record content allocated to a patient – programming errors
3. Records not retrievable as the staff put content in an unexpected place – operational ambiguity
4. Record contents read incorrectly off the screen – interface inadequacy and ambiguity
5. Work processes that are not optimal for the task to be performed – workarounds

This gives a mini taxonomy of faults which should be useful for future interpretation of who and what is needed to improve systems. For example, workarounds need to be understood as a failure of process design and require clinical led strategies for elimination. Technology solutions undefined by clinicians will only lead to complicating the poorly designed process.

Reference to “system usability” typically focuses on the traditional usability issues pursued by computer scientists and human factors investigators: the user interface. We would like to proffer a different perspective on the topic.

There are different factors in clinical information system usability and they require separation. The interface design is one, but what is also usability, which is often neglected but is arguably more important, is process usability. It is something that is macro to widget/screen real-estate, and is about the process clinicians need to follow to get their work done.

In our work on process design, we think of usability as the screen widgets and screen layout (typical human-technology interaction issues), but there is also data flow, the movement of data from the screen on which it is collected to the screens where it is used. Then there is workflow or process flow, where the processes of the staff are mapped to a system design that assists the staff in doing their work with patients. This involves things such as automatic movement from one screen to another, location of buttons or links to jump from one point in workflow to another, and delivery of contextual information required for decision making.

Our experience is that when working with the same clinical speciality in different institutions, their data collected is mostly the same, but their processes can be entirely different because the dependencies of the other disciplines around them supply services to them in very different ways.

In one tumour stream example, one department takes the patient case to the multidisciplinary team board before surgery; in another department, they take it to the MDM team after surgery. As process analysts, it is our job to support the processes of the clinical team, not to dictate what it should be.

In our opinion, the greatest determinant of a successful CIS (EMR) is the extent to which it supports the processes of the clinical teams and, subsequent to that, support for rapid process improvement.

Mike Bracken is having a significant impact in the UK Public Service IT delivery by introducing a new level of accountability to user needs. His background is in IT services for the Guardian newspaper, and he is bringing a refreshing emphasis on the need to put the users first, develop systems agilely and incrementally, and escape the cycle of large system project with very large corporations that lock in development resources for many years.

Bracken’s philosophy is appealing to us because it engenders our view of Clinical Team Led Design (CTLD) and the importance of rapid and economical adaptation and incremental expansion. It is important to get something working first that satisfies a given objective, and then to enhance it as confidence in the technology and competence in its use is established.

We would hope that we can add to Bracken’s article on the topic by emphasising that clinical systems, more than anything else, need to support the processes of the user, the clinical team, due to the high need for reliability, but concomitantly the need to support continuous process improvement for every local professional community.

We promote the view that for any one clinical discipline, e.g. emergency medicine, while the data collected from one department to another is nearly the same, the process is very different despite them being in the same speciality. This can only occur with a technology that makes it easy and cheap to change the processes and even allow a degree of experimentation with competing ideas.

Hence, our technology has these features:

1. Design is achieved by Clinical Team Led Design (CTLD). The design is automatically compiled into a run-time system by our unique software solution. Users are supported in the design process by our expert clinical analysts.

2. Designs can be changed in real time.

3. Data is shared with other disciplines by native interoperability based on an underlying lingua franca. (That is one thing Bracken did not mention in his article for enabling data to be shared across departments.)

4. Data Analytics is in-built (not provided by third-party software) as it is key to quality control and hence process improvement as managed by the senior staff.

5. A single software instance runs multiple clinical information systems, avoiding siloing of data and explosion of IT maintenance.

As our technology is driven by user designs, the future users are able to create a design, test it out and change it at will, ensuring that the go-live system meets immediate requirements and expansion can occur at a rate and in the direction they decide is most appropriate for their own setting.

Read Bracken’s original article here: On Strategy: The strategy is delivery. Again.