Tribulations of Working With a Clinical Information System

It is Interoperable …

Author

GurpreetDhillon

is Professor of Information

Systems at Virginia Commonwealth

University, US.

One Friday evening, my son insisted on riding his bicycle. I tried convincing him that that road was slippery, that he had to have his supper and that I was tired, but to no avail. Barely had he begun having fun when his cycle went out of control and he fell, breaking his left arm. Even though I am not an orthopedic specialist, I could see he had fractured both radius and ulna and that it was a green stick fracture.

An orthopedic surgeon friend advised me take my son straight to his clinic. My son, I must say, was rather brave all along. He cried a bit as his arm was being x-rayed and cried a little more while I filled in all the medical history forms, giving my consent to do “anything to my son”, taking responsibility if “anything would happen” and filling some more forms required by the HIPPA (Health Insurance Portability and Accountability Act). In my mind I was thinking, “how ridiculous, the point is that they go ahead and fix my son’s arm.”

My surgeon friend used his influence to get a slot at his preferred hospital for 11 pm. We arrived there one hour before. And it took the hospital staff close to one hour to check us in.

First Encounter: The Devil in the Details

This was my first brush with a hospital information system in the US.

First, the clerk could not figure out the codes that had to be inputted.

Then, she could not process my insurance online. She then had to call for an approval, take copies of my driving license and insurance card and then I waited, and waited. By now the ibuprofen was working on my son. His pain index was at 7, on a 10-point scale. Eventually the arm was put in a cast; another x-ray taken and we were discharged at 3 in the morning.

A Bumpy History to Seamless Interoperability

Clinical information systems have been around for a while, making their debut in the US in the 1950s with initial application in the dental arena. However, progress has been patchy. The quality of such systems has been inadequate and reliability poor.

In 2004, the US Department of Health and Human Services formed the Office of the National Coordinator for Health Information Technology for developing interoperable electronic health records.

Seamless interoperability can only be ensured if the clinical information systems are well designed and the hospitals have the competence to harness the technology.

Good Design and Defining Competence

Research into the design and delivery of clinical systems suggests that the quality of clinical information systems not only significantly varies from one implementation to the other, but in some cases the design itself is rather poor. To a large extent, this emanates from poor requirements specification. In many cases, developers pay lip service to identifying and specifying system requirements. While industry specified methods and procedures for requirements analysis exist, there is always an issue with respect to managing multiple stakeholders, their intent and perhaps organisational power relationships.

In the US, particular care also needs to be taken of what the physicians want, what the nurses require, what the administrators have need of and what the insurance companies require. Many a time the needs and wants of multiple stakeholders do not stack up; they are often at odds with each other. A clever systems analysis needs to balance out the conflicting requirements while the business analysts need to get all stakeholders on board, a task that is absolutely essential but not easy by any means.

All this suggests that hospitals must develop competence in managing IT and communication technologies. An inability to do so results in complete failure of systems. No wonder that the rate of failure of technology systems in hospitals is higher than that in regular businesses. Competence is an ability that helps translating know-how to know-that and vice versa.

The problem in clinical information systems is the cookie cutter approach adopted in most settings, which may or may not help in achieving the benefits. In most US hospitals, there is little emphasis on good change management while investing in the design and development of a new system. Rather, a techno- centric orientation forbids administrators and developers alike from understanding the context in which the system is being developed.

So What ?

Findings from various case studies have shown that balancing out the requirements and ensuring delivery of proposed benefits reduces resistance to adoption of new systems. The complexity inherent in the US healthcare system calls for even more careful consideration of stakeholder input.

Research has shown that failure of clinical information systems is largely because of:

Incompleteness of Driver Analysis: When analysts and developers approach the problem domain with certain predetermined conceptions, it often results in an incomplete analysis of critical drivers for change. In one hospital in the US, the ‘hows’ and ‘whats’ got mingled to a point such that the proposed benefits of the clinical information system for the whole hospital became obscured by benefits to a lower level task set. As a result, the intent behind the design and development simply got lost.

Ignored Drivers: In one British clinical information systems implementation, it was discovered that the hospital’s key motive was to move towards community-based care. However, the system developers largely ignored this main driver. The result was a system which did not quite manage to support community-based healthcare.

Method Drivers: On many occasions, system developers place too much faith in structured methods. They believe that their methodologies are robust and capable. Hence, they tend to focus on the process, rather than the intent or on what actually may be the problem. Consequently, endeavors get started as technology projects, with limited appreciation for the business.

Value Set Drivers: The total driver set within any organisation is a complex mixture of political, organisational and operational factors in which all parties have value sets that operate strongly. For example the government’s belief that the internal market strategy is very suitable for the UK National Health Service forces administrators to run hospitals with a rather different mind-set, which may not necessarily be in the best interest of the patients.

I am certain that if hospitals focus a little more on defining requirements, shun the cookie-cutter approach to defining and designing systems and put a little more emphasis on competence building, the results will be spectacular.

On my part, I am certain that my son’s arm would have been fixed hours earlier and would have avoided the trouble of filling out multiple forms and giving an equally extensive multitude of consents – while he was in pain. Would it not have been nicer if a majority of such activities were automated ?

For instance, initiating one activity in a physician’s office should have automatically led to checking-in my son into the preferred hospital. I could then have been prompted to confirm the choices, via email or cell phone. This would clearly help eliminate a lot of flab from the current business process.

If banks and investment brokers can use such a process, why cannot hospitals and insurance companies ? Only after we achieve such a level of networked co-dependence, I will call it complete interoperability.