Month: November 2013

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.