Jon Patrick

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.

The Implementation Special Interest List of AMIA has been recently discussing the issue of whether Health IT can reduce the costs of health care. Reference was made to this article: Doctors Say Health IT Will Result in Higher Costs, Report Finds, which prompted one contributor to ask if there was any evidence that HIT reduced costs. Our comments follow this request:

There is every reason to predict that BadHIT will increase costs for these reasons:

1. BHIT gives more attention to recording more detail about the clinical encounter with the objective of identifying more billable items — this puts up cost because staff spend more time recording information and so can see less patients, plus the charges for any given episode of care go up as more chargeable items are recorded.

2. There is no evidence that BHIT produces significant enough improved patient outcomes with fewer bad health episodes so that the patients’ decrease in attendance offsets the increase in costs for the earlier attendance — that is, there are no downstream advantages demonstrated.

3. GoodHIT also has a credibility gap on these two types of evidence but it has one saving grace — staff believe and in some cases can show that GHIT enhances their work activities — this leads to improved morale amongst staff, which is likely to lead to improved productivity or at least no loss of productivity — this in turn is likely you lead to more caring care if not improved outcomes so it should at least register in comparative patient satisfaction surveys, if nothing else.

4. The real gains in HIT will be found when the price of HIT drops by a factor of 10 and the clinical teams can design systems that match their workflows without the software engineers getting in their way.