Author: Jon Patrick

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

The challenge for today’s systems developers is to take a new approach to interoperability that removes the barriers of the old ways of working on the generation of software built from the 1970s onwards. The relational data model demanded that the tables for storage be defined by the programmer, whilst the definition of the data fields was produced by the systems analyst. Hence, the definition of data was separated from its storage organisation. If the storage variables (table names and field names) had been kept strongly linked to field definitions in the first place, then the interoperability problem would be much less than it is today.

Keys to better interoperability today are:

1. Properly defining the meaning of fields of data by engagement of clinicians or clinical terminologists in the data definition process.
2. Removing the dependency on understanding tables and attribute naming by removing that step entirely from the development process – that is, automatically create the data structures for storage from the design, so there is only one point of data definition: in the design.
3. Providing the names to fields of data by a taxonomically stable source of names e.g. SNOMED CT or like taxonomies.
4. Accessing the data by its definitional name and providing tools such as APIs that enable one system to learn another systems naming conventions.
5. Ultimately, data should be transferred by reference to its stable name without the needed for HL7 message to create a payload, or without ODBC calls to directly access data tables.

The article titled In the future customers, not companies, will manage the relationship published in The Age earlier in March may not seem relevant, but it is a salutary message for us.

The advent of Customer Relationship Management (CRM) is in part parallel to the rise of EMR usage throughout the 80s and 90s, and is part of the Enterprise Resource Planning (ERP) movement that was driven so effectively by SAP. The ERP movement entered the clinical sphere with rise of big HIT and has reached its pinnacle with the Meaningful Use (MU) movement.

The disappointment with the clinical ERP technology is a mirror of CRM in this article when you map their “customers” to our “clinicians”, but we haven’t yet seen the same reaction to bringing forward a new technology.

By far, our most common experience in the health IT space is that clinical staff are disenfranchised from improving their IT because of the expense and difficulty of getting vendors to honestly and truthfully participate in a partnership of continuous process improvement. The older vendors have some legitimate excuse for avoiding software modifications because of the expense to them and the higher risk of making things worse due to the complexity of their software. That nevertheless leaves the clinicians frustrated with no way out of dead-end.

This is the exact reason for our architectural design where the system can be changed in real-time without the need for any programming. The staff can not only design their own system, but experiment with ways of changing it, and even revert when new ideas turn out not to be as smart as they thought they were. The bottom line is that the software has to support continuous process improvement.

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